Tuesday, April 30. 2019
Upgrading tissot to LienageOS 16
Just a very quick entry today. The previous weekend I wasted a lot of time trying to upgrade my phone to LineageOS 16. In general I followed the upgrading guide for my phone model but when I started the adb sideload it always failed with the error: "Error applying update: 7(ErrorCode:: kInstallDeviceOpenError)". I tried Friday evening with no success, I was searching for information a couple of hours at Saturday and I finally got it working on Sunday. I think summarizing what was needed in the blog would be better, maybe it is useful for someone else.
In general the reason seems to be that tissot (my phone model, Xiaomi Mi A1) needs something special in the TWRP boot loader. Finally I got it working after reading this beautiful issue. The problem is explained by the maintainer himself in this thread. My model, unlike most of the usual A/B devices, has a weird partitioning where most partitions are not slotted (except of boot, system, modem). By default, TWRP does not expect to have any non-slotted partition in the A/B OTA package. That is why the installation fails on all TWRP packages except the one provided by the maintainer. So, if having this model, you need to download that exact TWRP image in order to upgrade the system.
After using the correct TWRP version everything went successfully and I have LineageOS 16 in my phone. The main problem was finding the issue, I needed to google a lot until I found that page which described my exact problem.
Regards!
Sunday, March 3. 2019
Emulating the AD range attribute retrieval feature
Another quick entry today, I have been involved in a keycloak problem with windows AD. The issue can be summarized in the idea that the Active Directory, when an entry has a lot of values in one attribute (usually a group entry with a lot of users inside member), not all of them are returned by default. There is a MaxValRange limit that controls when the AD starts to omit values and return the values in ranges. Microsoft documents this feature in this note Searching Using Range Retrieval with some useful examples.
Configuring the limit to its lower value (30) in one of my demo envs the results in my tests were the following:
Retrieving the members from a group with 31 users activates the limit, and only 0-29 values are returned.
ldapsearch -LLL -h sampleserver.sample.com -D "cn=Admin,cn=Users,dc=sample,dc=com" -w XXXXX -b "CN=InnerGroup,ou=groups,dc=sample,dc=com" -s base objectclass=* member dn: CN=InnerGroup,ou=groups,dc=sample,dc=com member;range=0-29: CN=aduser5 aduser5,CN=Users,DC=SAMPLE,DC=COM member;range=0-29: CN=aduser4 aduser4,CN=Users,DC=SAMPLE,DC=COM ... member;range=0-29: CN=Administrator,CN=Users,DC=SAMPLE,DC=COMThe missing entry can be obtained requesting more data from 30 to the end (* means the the last attribute value):
ldapsearch -LLL -h sampleserver.sample.com -D "cn=Admin,cn=Users,dc=sample,dc=com" -w XXXXX -b "CN=InnerGroup,ou=groups,dc=sample,dc=com" -s base objectclass=* "member;range=30-*" dn: CN=InnerGroup,ou=groups,dc=sample,dc=com member;range=30-*: CN=aduser6 aduser6,CN=Users,DC=SAMPLE,DC=COMYou can also request just a specific range of the attribute (for example entries 28-29):
ldapsearch -LLL -h sampleserver.sample.com -D "cn=Admin,cn=Users,dc=sample,dc=com" -w XXXXX -b "CN=InnerGroup,ou=groups,dc=sample,dc=com" -s base objectclass=* "member;range=28-29" dn: CN=InnerGroup,ou=groups,dc=sample,dc=com member;range=28-29: CN=aduser5 aduser5,CN=Users,DC=SAMPLE,DC=COM member;range=28-29: CN=aduser4 aduser4,CN=Users,DC=SAMPLE,DC=COMIf the upper limit is greater than the current number of values in the attribute * is returned to mark that the last value was reached:
ldapsearch -LLL -h sampleserver.sample.com -D "cn=Admin,cn=Users,dc=sample,dc=com" -w XXXXX -b "CN=InnerGroup,ou=groups,dc=sample,dc=com" -s base objectclass=* "member;range=29-40" dn: CN=InnerGroup,ou=groups,dc=sample,dc=com member;range=29-*: CN=aduser6 aduser6,CN=Users,DC=SAMPLE,DC=COM member;range=29-*: CN=aduser5 aduser5,CN=Users,DC=SAMPLE,DC=COMWhat happens if the upper range requested is wrong or less than the start range? Just one element is returned.
ldapsearch -LLL -h sampleserver.sample.com -D "cn=Admin,cn=Users,dc=sample,dc=com" -w XXXXX -b "CN=InnerGroup,ou=groups,dc=sample,dc=com" -s base objectclass=* "member;range=29-10" dn: CN=InnerGroup,ou=groups,dc=sample,dc=com member;range=29-29: CN=aduser5 aduser5,CN=Users,DC=SAMPLE,DC=COMAnd if the start position is wrong? An error is returned.
ldapsearch -LLL -h sampleserver.sample.com -D "cn=Admin,cn=Users,dc=sample,dc=com" -w XXXXX -b "CN=InnerGroup,ou=groups,dc=sample,dc=com" -s base objectclass=* "member;range=50-*" Operations error (1) Additional information: 00002121: SvcErr: DSID-031206B8, problem 5012 (DIR_ERROR), data 8995
So the range retrieval is easy to use and understand but my main problem was that I needed to test this feature inside keycloak. The basic tests use the apache directory server embedded inside the same java code to test everything with maven. This range retrieval feature is very AD specific (I do not know any other LDAP directory that performs the same) so the Apache implementation does not do the same by default. But the project lets you implement your own interceptors. And, no sooner said than done, I implemented a ranged interceptor to emulate AD behavior. My implementation is very easy, it only applies to one attribute that should be specified, but range attribute value retrieval can be emulated in an embedded LDAP server for it, so I can write some tests to check if the implementation is working smoothly.
The entry's goal is just saving my interceptor here. It is just one class and some easy junit tests that check everything is working, but better if the class is saved here. The maven project can be downloaded from here.
Best regards!
Saturday, January 19. 2019
OpenWeatherMapProvider needs to be compiled again for Lineage 15.1
Short entry this time to upload the OpenWeatherMapProvider APK to the blog. More than two years ago I wrote another entry about this same topic and how I needed to compile the OpenWeatherMap provider for CyanogenMod 13. Since them I have been using the same APK file in CM 13 and Lineage 14 but, it seems that it's not valid anymore in version 15.1. I have just retired my old phone and in the new one the old APK was not working (it was installed without issues but then the weather app did not detect any provider installed).
So, after knowing that there are APKs available for other providers but not for OpenWeatherMap, I repeated the same steps than in my old entry.
git clone https://github.com/LineageOS/android_packages_apps_OpenWeatherMapProvider.git
cd android_packages_apps_OpenWeatherMapProvider/
git checkout lineage-15.1
./gradlew
./gradlew build
This time I changed to branch 15.1 although it was unnecessary (the are no differences between branches 15.1 and 16.0). I received a rebuke the previous time so here you have the debug OpenWeatherMapWeatherProvider.apk. You can compile it by yourselves if you do not trust me (I would not do it). It is nice to see my new phone smoothly working now with lineage OS 15.1.
Best regards.
Comments