How to modify your „hosts“-file on Android

Context

I am using LineageOS 14.1 which has Android 7.1.2 as base. My phone is not rooted, because there is no reason for me to have root access. As i wanted to keep it that way, I used TWRP to change the „host“-file. Unfortunately this broke the host file lookup. So I am documenting here a correct way to do it.

Preparations

First of all we want to use ADB (Android Debugging Bridge). This way you can have root shell access to Your phone from Your PC.

You need to download the Android SDK from https://developer.android.com/studio/#downloads. Unzip it somewhere you like.

Then connect your phone with you PC using USB. Go to your settings, scroll down to development settings. Activate Root access for ADB and USB-debugging.

Now open a command-line on your PC and navigate to the Folder you extracted the Android SDK.

adb root
adb shell

Making the Modification

The „hosts“-file is located under /system/etc/hosts. You can not start right away. /system is mounted as read-only partition. To modify it you need to make it writable. You use the following mount command for that.

mount /system -o remount,rw

Now you can write some stuff to the „hosts“-file. I chose to use one from someone who cares http://someonewhocares.org/. Obviously this only works if your phone has a active internet connection.

wget http://someonewhocares.org/hosts/zero/hosts >/system/etc/hosts

After you ‚re done, make sure to mount the system partition read-only again.

mount /system -o remount,ro

Now you should test it by running using the ping command with one of the hosts you just added.

If it works, you can disable USB-debugging and ADB root access. You should reboot your phone to check if this works too.

Problems I encountered

Back to the problems I mentioned at the beginning of this Article. When I first tried to modify my „hosts“-file, I got stuck by ping and every other application ignoring the file.
This was because of SELinux detecting the modification and blocking access to the modified file. I think I changed the inode somehow. You should check the kernel messages with dmesg |grep host command. To see if the SELinux is complaining.

I was able to fix this problem with restorecon command. It seams to be part of SELinux and is able to restore security contexts.

restorecon /system/etc/hosts

Here is some Documentation about the restorecon command. https://fedoraproject.org/wiki/SELinux/restorecon

I could not reproduce the error I got, when I was copying the a new hosts file using the recovery. Maybe you are always fine when you overwrite the content of the file with a command like this.

cat newhostsfile >/system/etc/hosts

Migrating ownCloud from sqlite to MySQL and dropping ownCloud alltogether

No backup, not pity. You need to know what you are doing and don’t blame me for your broken ownCloud.

Recently, I was upgrading my ownCloud installation from 9.1.x to 10.0.x, Cause I like to keep my stuff up to date. This was fairly easy through the admin interface. After the update, there where some recommendations about using a „memcache.filelock“. The Redis-setup was quite easy too. The 2nd recommendation was about using MySQL instead of sqlite. For my very small installation, sqlite should have been quite enough, but the ownCloud console „occ“ offers an automated conversion script. So I thought to myself: Why not?

Trying it automatically

This didn’t work for me!

You simply have to create a database for ownCloud and run this command. You will be asked for the password of the database connection.

sudo -u www-data php occ db:convert-type --clear-schema --all-apps -- mysql owncloud localhost owncloud

The script also updates the database-type in the Configuration file „config/config.php“. But there are bugs in the conversion script documented at github, namely #28223 and #27075, that hit me too. So I decided to convert the database manually. There are several tools to help us with this.

Doing it manually

I started with converting the database to match the xml database scheme in „db_structure.xml“ using the „occ“-command. Putting ownCloud into maintenance mode should be a good idea too.

sudo -u www-data php occ maintenance:singleuser --on
sudo -u www-data php occ db:generate-change-script |sqlite3 data/owncloud.db

Now you need to dump the sqlite database and load it into MySQL. Unfortunately the sqlite dump is not compatible with MySQL, but it can be converted. You can find a script called „sqlite3-to-mysql.py“ on several locations on the internet. Good old „sed“-command might have worked too. The script only removes and replaces some lines. It also needed some extra replacement rules to it.

...
 "COLLATE BINARY": "COLLATE utf8_bin",
 "CLOB": "LONGTEXT",
 ", lock ": ",`lock` ",
...

sqlite3 data/owncloud.db .dump >dump.sql
cat dump.sql|./sqlite3-to-mysql.py|mysql owncloud

Afterwards there where still some differences between „db_structure.xml“. So I ran the change-script-generator again.

sudo -u www-data php occ db:generate-change-script|mysql owncloud
sudo -u www-data php occ db:convert-mysql-charset

This removes „execution_duration“ column from „oc_jobs“ table. This is because of an error in „db_structure.xml“. So I added „execution_duration“ back again afterwards. This could be the cause for #28223.

Dropping ownCloud in Favor of NextCloud

After thinking about the Bugs I encountered, I decided to change from ownCloud to NextCloud. On the NextCloud manual, the procedure is just like a manual update. Everything worked fine, without any problems. ownClound 10.0.7 -> NextCloud 12.

chroot Jail für SFTP und SSH mit minimaler Shell

Einleitung

Möchte man Anwendern Webspace bereitstellen, muss man diesen Anwendern irgendwie ermöglichen dort Dateien hoch zu laden. Gleichzeitig sollten die Anwendungen die dann von dem Webserver ausgeführt werden auch nur Zugriff auf diese Dateien haben. Jeder Benutzerkontext sollte gegen die anderen abgeschirmt werden. Manchmal wünscht sich dann jemand doch noch einen Shell-Zugang. chroot Jail für SFTP und SSH mit minimaler Shell weiterlesen