Not enough space on boot partition
When your ubuntu distribution is installed using the LVM partition system, you can run into an issue while performing updates and upgrades of the distribution because, at some points, the /boot
partition becomes too small. This results in messages of this type:
Not enough free disk space The upgrade has aborted. The upgrade needs a total of 617 M free space on disk '/boot'. Please free at least an additional 282 M of disk space on '/boot'.
When this happens,
- check the content of your
/boot
partition (withls /boot
) and remove all unused kernels. This can be performed withsudo apt autoremove --purge
or, if you have old kernels and images, this sometimes require that you remove them one by one by removing thelinux-headers-...
andlinux-images-...
packages along with the remaining files in/boot
; - if this is still not enough, edit (as sudo) the file
/etc/initramfs-tools/initramfs.conf
and change the lineCOMPRESS=lz4
toCOMPRESS=xz
and runsudo update-initramfs -u -k all sudo apt autoremove --purge
This should be enough to solve the problem.
nextcloud was extremely slow (and how I solved it)
Nextcloud was extremely slow since a couple of months: all tentative to synchronize tasks or even keepass2 file on android failed, updating the task list in nextcloud took more than 10 minutes and connexion to the web interface also took several minutes. I tested a few things to improve performance and ended up finding the origin of the problem and fixing it.
Configuring caching
Reference: Nextcloud documentation
One of the main source of performance improvement for nextcloud is supposed to be a proper configuration of caching with redis. It can be installed using:
sudo apt install redis-server php-redis
and the installation is properly made (and server started) if the following command line
ps ax | grep redis
returns something like:
1920663 ? Ssl 0:00 /usr/bin/redis-server 127.0.0.1:6376
(the port is usually 6379 instead of 6376).
Then, nextcloud has to be configured to use redis for caching. I used the following setting, entered into the `config/config.php` file of the nextcloud installation directory:
'memcache.local' => '\OC\Memcache\APCu', 'memcache.distributed' => '\OC\Memcache\Redis', 'redis' => [ 'host' => '/run/redis/redis-server.sock', 'port' => '0', ], 'memcache.locking' => '\OC\Memcache\Redis',
which uses redis through a socket. The socket itself is configured by editing the file `/etc/redis/redis.conf` and by checking the unix socket path:
unixsocket /run/redis/redis-server.sock
Finally, make sure that redis is in the group `www-data` and restart redis and apache2 to ensure the proper use of the updated settings:
sudo usermod -a -G redis www-data sudo systemctl restart apache2 sudo systemctl restart redis-server
Increasing swap size
Another problem that I encountered was the fact that my memory was almost entirely used and that the swap was full (use `top`, `htop` of `free -h` to check your memory usage). After having killed some of the processes that were running for a while, I freed swap in order to setup a larger swap file:
swapoff -a
I doubled the swap size to 1Mb by creating a swap file with the following command line:
sudo dd if=/dev/zero of=/media/swapfile.img bs=1024 count=1M
on which I put proper permissions and that I registered as a swapfile:
chmod 600 /media/swapfile.img mkswap /media/swapfile.img
To make the change persisting even after reboot, I also edited the file /etc/fstab
to comment out the previous line corresponding to the former swap (/dev/sda3
in my case) and to replace it by the following line:</p>
/media/swapfile.img swap swap sw 0 0
Setting properly CRON for maintenance tasks
Reference: Nextcloud help page on background jobs
However, none of these two previous fixes solved my main issue. I also noticed that nextcloud was slow for my user but not for some other user (for instance, I have a user dedicated to administration of the app that was not having the same type of issue). I then found out [this conversation](https://github.com/nextcloud/server/issues/6203) and saw that the exact same problem was occuring with me: logged on the web interface, in "Personal settings/Security", I had thousands of reported opened sessions).
As the admin user, I thus went to "Administration settings/Administration/Basic settings" and set background jobs to be run through CRON (last option) instead of AJAX. In parallel, on the server, I first run the maintenance task once through the command line, from within the nextcloud installation directory:
sudo -u www-data php -f cron.php
This task took a long time to run (approximately 15 minutes I would say) but ended up with no error and the old sessions from my user account were revoked. The connexion to this account from my smartphone, thunderbird and the web interface became normal again. Most of the opened sessions have been generated by DAVx5 so I'll keep an eye on it in the future.
To finish, I also set up an automatic task to run the CRON script regularly. Advised frequency is 5 minutes but since the previous run took more than this time, I set a frequency time of 60 minutes, which should be enough for my personal instance:
crontab -u www-data -e
and adding the line
*/60 * * * * php -f /var/www/nextcloud/cron.php
properly sets the CRON job.
grub-efi-amd64-signed kept back during upgrade
A recent upgrade of my package versions on Xubuntu 22.04 LTS led to the following error:
The following packages have been kept back: grub-efi-amd64-signed
where, indeed, the package `grub-efi-amd64-signed` could not be updated. The reason is that the list of dependencies related to this package has changed. The following command line fixes the upgrade:
sudo apt install --only-upgrade grub-efi-amd64-bin
Getting rid of firefox based on snap on Ubuntu 22.04
Since Ubuntu 22.04, firefox is based on snap, with various side effects, including inability to download files in fuse.fs mounted partitions. This post explains how to install firefox from mozilla repository instead.
Special thanks to Stéphanie who had a problem with her mounted partitions and pointed the issue to me so that I could fix it for her!
Important warning! Before you start, be sure to have saved your user profile (it is especially important if firefox stores for you your passwords or other login information). This can be done:
- either by activating your firefox sync account. In this case, activating the same sync account on any brand new firefox will automatically activate your formally saved passwords and downloaded plugins;
- or directly save the snap user profile (included in
~/snap/firefox/common/.mozilla/firefox
). After firefox has been reinstalled, it can be copied into~/.mozilla/firefox/
.
Special thanks to >Pierre who had to experience the loss of his data and pointed that issue to me.
Finally, to install the mozilla repository based version of firefox, first remove firefox based on snap:
sudo snap remove firefox
and add mozilla PPA in you source list:
sudo add-apt-repository ppa:mozillateam/ppa
Then, as sudo, create a file /etc/apt/preferences.d/mozilla-firefox
where you put the following lines:
Package: * Pin: release o=LP-PPA-mozillateam Pin-Priority: 1001 Package: firefox* Pin: release o=Ubuntu Pin-Priority: -1
To finish,
sudo apt update sudo apt upgrade sudo apt install firefox
should be enough to properly install firefox (and as an extra surprise, install a better version of thunderbird, compatible with more plugins, including the TbSync plugin that is the only one to handle Active Directory synchronization and is not functional in Ubuntu official release of thunderbird).
Encrypting some files in git repositories with git-crypt
This post describes how to encrypt some files (containing secrets) in git repositories in a transparent way. The chosen solution encrypts files before they are pushed to the remote and decrypts it at pull locally (so you have to make sure that your secrets are well protected on your local computer).
Different tools exist to perform this task, including BlackBox, SOPS, transcrypt, git-secret. I chose git-crypt because it is available through a Ubuntu package, is really fully transparent, is well referenced, cited, and used, is regularly maintained, and can work over GnuPG.
First step: as a maintainer, initialize your git-crypt repository
git-crypt is easily installed with apt
(install gnupg if you do not have it installed already):
sudo apt install gnupg git-crypt
Locally, initialize your git repository as usual and add the git-crypt initialization afterwards:
git init git-crypt init
Then, create a .gitattributes
file including the list of files and directories that you want encrypted in your remote repository:
secretfile filter=git-crypt diff=git-crypt *.key filter=git-crypt diff=git-crypt secretdir/** filter=git-crypt diff=git-crypt
Note that, to include all files of a given directory secretdir/
, the syntax is secretdir/**
and not secretdir/*
!
GnuPG users can be added by ID or email by:
git-crypt add-gpg-user tuxette@my-domain.org
This creates an encrypted GPG key within .git-crypt/keys
, which is automatically commited.
More information on GnuPG is available at this page (unfortunately in French).
Then, configure your remote directory (supposed, here, to be empty; this is done with git remote add ...
), add and commit all the files that are supposed to be versionned, in addition to the file .gitattributes
and push. Further add, commit, pull, push commands can then be used as usual.
Second step: as a new user to an existing repository, set your git-crypt configuration
You need first to install gnupg and git-crypt with:
sudo apt install gnupg git-crypt
Then, start by generating your GPG key (if you don't have one already) with:
gpg --gen-key
Once done, you can check it with:
gpg --list-keys
that should look like:
pub rsa4096 2016-10-31 [SC] 551C582A867ABF1865E86006378CDF2A339F144E uid [ultimate] Tuxette Chix <tuxette@my-domain.org> sub rsa4096 2016-10-31 [E]
which you can export using
gpg --armor --export 551C582A867ABF1865E86006378CDF2A339F144E > my_public_key.pub
(the ID 551C582A867ABF1865E86006378CDF2A339F144E
has to be adapted to your own key). Send this file to the repository admin and waits for her/him to allow you to access the git-crypt repository.
When everything is ready, all you have to do is simply:
git clone gitolite@git.my-domain.org:my-nice-git-repo.git git-crypt unlock
You can then add, commit, pull and push as usual.
Second step bis: as an admin, add a new user to use secrets
When a new user sends her/his GPG key, add it to your GnuPG configuration with:
gpg --import new-public-key.pub
You can check that it has properly been added with
gpg --list-keys
You may need to "trust" the key before you can proceed. You can do it by signing it:
gpg --edit-key 551C582A867ABF1865E86006378CDF2A339F144E
then type sign
, quit
, and finally yes
to save the edition of the key.
Finally, in the git repository, run:
git-crypt add-gpg-user <new_user_email@other-domain.org>
where the email is the one referenced in the key (you can also add a user with the key ID). Do not forget to push the changes (the new user's encrypted key)!