Yaal Coop - linux

Purism Librem 5 software review : our list to Santa

2022-06-02T00:00:00+02:00

After several years of waiting, we just received our Librem 5 phone from Purism. The Librem 5 phone is a privacy-oriented phone which notable features are:

it uses PureOS, a GNU/Linux distribution based on Debian, instead of Android or iOS;
the interface is based on GNOME with a few modifications;
it has kill switches to physically disable wifi, bluetooth, cellular data, camera and microphone.

Running a Linux on a cellular phone enables new uses, especially for tech savvy, but it comes with its lot of drawbacks. The main notable ones is that Linux phones is a brand new field, and a lot of apps are simply 'not ready'. Either because their UI is not adaptive, because they have not been adapted to mobile user interactions (swiping and other gestures), or just because they have not been tested enough by users, so some actions feels convoluted.

FOSS developers do their best, and a whole lot of great work has been done so far. However we are not yet at a point where Linux phones can be put in the hands of a larger audience. With our fresh eyes of new Linux mobile users, we want to list here the main things that we felt were really missing to provide a good user experience (at least for our biased geeky use). We focused on GNOME Core and Circle apps, and mobile/Librem5 specific apps developed by Purism. What we expect from a phone is to:

place calls
receive and send SMS
receive and send emails
be used as an alarm clock
manage contacts
manage tasks
be used as a geolocation navigation device
browse the internet
play music
take photos
take notes
display documents
share internet connection
be used as a torchlight
discuss with people

As patching has even more value than reporting, this list could be used by us (or you?) as a to-do list for some day if we get bored.

We have tested the phone running PureOS byzantium, and we updated all the apps through Flatpak when possible so we could get the latest GNOME 42 fixes.

Blockers

In this category we put the issues we feel are very discouraging for a daily use. This mainly concerns UX friction and stress, and missing or broken features.

Squeekboard - Alternate characters popovers: We Europeans use a lot of diacritics, the keyboard should offer us a way easily write any common accentuated character.
Librem5 - Translation have to be forced: At first launch, the welcome panel asks the user for their language, but this action is uneffective and the system is displayed in English after that. This is easy to fix with a command-line, but surprising for a first-launch.
Clocks - Alarms should ring even when the application is not launched: If an alarm has been set, it should ring on time, no matter what. Having to launch the application to get the alarm ring is unexpected.
Clocks - Alarms should wake the system up: If an alarm has been set, it should ring on time, no matter what. Alarms should wake the system up if needed.
Clocks - Custom alarm sound: At the moment, the only alarm sound is the default one.
Clocks - Interact with an alarm from the lock screen: Currently it is needed to enter the PIN code before we can stop the alarms. When you wake up, this is harsh.
Squeekboard - Input indicator: When a key is tapped, users should have a visual indication of which key is actually pressed.
Librem5 - Night light support: GNOME provide a night light feature that reddish the screen automatically depending on the hour. It seems there are some kernel thing to do to enable this. Without this, watching to the screen at night just kill your eyes.
Calls - Alphabet side bar: The application lacks an alphabet side bar to quickly jump to some letters in the contact list. With thousands of contacts this would become more than useful.
Contacts - Alphabet side bar: The application lacks an alphabet side bar to quickly jump to some letters in the contact list. With thousands of contacts this would become more than useful.
To-Do - Adaptive UI: The UI is not adaptive at the moment, so To-Do is not usable.
Weather - Adaptive UI: The application is not adapted to mobile UI.
Fractal - End-to-end encryption: At Yaal Coop we encrypt our conversations, so E2EE in Fractal is a blocker to us.
Maps - Adaptive UI: The side-menu is not usable on a Librem 5 at this point.
Maps - Navigation view: The application can calculate itineraries, but do not provide anything to follow the itineraries. Is is not usable in a car yet.
Maps - Long-press to open the contextual menu: Some actions are only accessible via right click on desktop, so on mobile they just cannot be done. A long press on the map should have the same effect as a right click.
Online Accounts - CarDAV & CalDAV provider support: This would allow to plug any contact, calendar and todo list provider to the system.
mobile-broadband-provider-info - TeleCoop support: This allows to use data with TeleCoop. The patch is applied but not yet deployed.
Software - UI is sluggish: When Flatpak in enabled, any actions takes decades to achieve, to the point that it is sometimes needed to restart the app.
Voicemail - There is no working voicemail app at the moment: Having the ability to easily listen to voicemails is a must-have on a 2022 phone.

Comfort

In this category we put the issues that would improve our comfort. This mainly concern mobile UX improvements.

Phosh - Automatic light and dark theme switch: Along with the screen warmness adaptation, switching from a light to a dark theme when the night comes is a bliss for the eyes. This is achievable with GNOME Shell with the Night Theme Switcher extension for instance.
Phosh - Swipe to open and close the menu: As of today, the application menu and the top menu can only be opened by tapping. However swiping to open the menu feels more natural on mobile. This have been implemented but not yet deployed.
Phosh - Automatically unlock the keyring: When opening a new session with a PIN, it is then asked a second time to unlock the GNOME keyring. This feels redundant.
Phosh - Hold the volume buttons to change volume: Currently, we have to press the buttons multiple times in order to change the volume.
Librem5 - Ask the encryption passphrase at first boot: At first boot, a (default) passphrase is asked to decrypt the disk, in English, with a qwerty keyboard. It would be friendlier to not ask it a the first boot and let the user choose it.
Librem5 - Disk decryption screen l10n: The disk decryption screen is in English, with a qwerty keyboard, so it is not adapted to other languages.
Phosh - Keep the time displayed when the top menu is opened: The time is hidden when the top menu is opened. Time is still an interesting information to display when the menu is opened, and without this the top bar appears strangely empty. This seems to be fixed but not yet deployed.
Phosh - Toggle geolocation from the top menu: In the top menu there are button to toggle wifi or bluetooth, but not to toggle geolocation.

Sparkles

In this category we put everything else that we met during our test, from nice-to-have features to slight mobile UX improvements:

Chatty - Swipe to return to the message list: When a message is displayed, there is an arrow button that allows to go back to the message list, but the more natural action on mobile would be to swipe left.
Geary - Swipe to return to the message list: When a message is displayed, there is an arrow button that allows to go back to the message list, but the more natural action on mobile would be to swipe left.
Calendar - Swipe to navigate between weeks or months: Swipe would be more adapted to mobile screens than the current arrows.
Calendar - Selection visual indicator: During a selection on touchscreen, users have no feedback until their finger is released.
Calendar - Adaptive UI: Calendar displays good enough on mobile, but some details are missing. For instance, the tooltips can be larger than the screen.
Clocks - Analog watch widget: Tapping multiple times on the screen to select hours and minutes is cumbersome. An analog watch widget could achieve the action in on two taps.
Disks - Adaptive UI: The encryption menu is not adaptive, but this is still usable.
Dialect - Slow performances at startup: The applications takes several seconds to start.
Dialect - Cannot close the preferences dialog: It has a close button on GNOME Shell, but not on phosh.
Dialect - Offline translations: Because we are not always connected.
Maps - Offline maps: To save mobile data, it would be better to pre-download maps and routes on a Wifi connection for instance.
Dictionary - Offline dictionary: Currently, an internet connection is needed to use the app.
Evince - Automatically switch to night mode: Evince allows to manually invert the background color at night. This should be done automatically depending on the system dark mode.
Maps - Double-tap to zoom: On desktop double-clicking zooms, as should do double-tapping on touchscreen.
Squeekboard - Bépo support: This one does only concerns a few nerds, but bépo (a French dvorak layout) support would be awesome.
Geary - Image banner is not adaptive: The image display banner does not display well on mobile.
Web - Password banner is not adaptive: The password banner does not display well on mobile.
Backups - Adaptive UI: The home screen does not display well on mobile.
Librem5 - Mobile data traffic counter: This would be a useful utility when data is limited.
Furtherance - Home screen is not adaptive enough: The French translation of the application provokes UX adaptivity issues.
Notes - Adaptive UI: Notes is not yet adaptive.
Settings - Bluetooth screen is not adaptive enough: As usual, some French content makes the panel too large.

How to plug OpenSMTPD with OpenLDAP on Debian Buster

2019-12-27T00:00:00+01:00

So you want to host your own mail server with opensmtpd, but you don't have time to understand everything going on? Here is an expeditious guide for doing just that.

In this guide I used OpenSMTPD 6.6.1 on Debian Buster.

Lets start by blindly copy-pasting this snippet to install the dependencies we will need:

sudo apt install opensmtpd libpam-ldap libnss-ldap

OpenSMTPD

OpenSMTPD has some LDAP support with the opensmtpd-extras package, but not enough for LDAP authentication. Someone opened a bug report stating that you can request some fields from the LDAP server, giving you access to the hashed user password, but that's it. You do not know which hash algorithm was used, and even if you did, OpenSMTPD will only use the one provided by crypt, so there is a good chance that comparing hashed passwords won't work. Later, an OpenSMTPD developer confirmed that there was no such thing as LDAP authentication in OpenSMTPD, but that one should rely on standard authentication mechanisms such as PAM or bsd_auth:

[...] OpenSMTPD authenticate using crypt(3) by default, which indeed will require credentials to be adapted for that function, but it does so through bsd_auth(3) on OpenBSD and may be configured to use pam(3) on other systems, so you may just delegate authentication to an ldap layer if you actually don't want the system's auth to take place.

This seems like the right approach to tackle this issue to me, if I were to authenticate against ldap, I'd use an ldap authenticator for bsd_auth(3) or pam(3).

Here is an example of a /etc/smtpd.conf file.

pki mail.mydomain.tld cert "/path/to/fullchain.pem"
pki mail.mydomain.tld key "/path/to/privkey.pem"
pki mail.mydomain.tld dhe auto

public_addr = "xxx.xxx.xxx.xxx"
listen on $public_addr port 465 smtps pki mail.mydomain.tld auth
listen on $public_addr port 587 tls-require pki mail.mydomain.tld auth

table ldap ldap:/etc/mail/ldap.conf

action dovecot lmtp "/var/run/dovecot/lmtp" userbase <ldap>
action "relay" relay

match from any for domain "mydomain.tld" action "dovecot"
match from any action "relay"

Note that the userbase parameter is not directly linked with user authentication. It actually defines the list of available recipients. Here is an example of /etc/mail/ldap.conf:

url                     ldap://ldap.mydomain.tld
username                cn=admin,dc=mydomain,dc=tld
password                MyAmazingPassword
basedn                  ou=Users,dc=mydomain,dc=tld

userinfo_filter         (&(objectClass=posixAccount)(uid=%s))
userinfo_attributes     uidNumber,gidNumber,homeDirectory

Without further configuration, the auth keyword in smtpd.conf tells OpenSMTPD to use PAM authentication. So this is what we should now configure.

PAM

According to its man page, PAM is a system of libraries that handle the authentication tasks of applications (services) on the system. In Debian, it mainly consists of a collection of configuration files in /etc/pam.d for programs that need a generic way to handle authentication, session management, etc. Each file is a set of rules for one program. Those rules generally use a pam_foobar.so file depending on the method used (unix, ldap etc.). The idea is to chain rules to define an authentication policy (e.g. try to authenticate against the unix backend, if that fails try against LDAP, then if that fails reject the user). By default, OpenSMTPD will look into the /etc/pam.d/smtpd file for its rules, so this is where we want to write some configuration. The pam_ldap.so module we are interested in is provided by the libpam-ldap package.

Here is an example of a /etc/pam.d/smtpd file.

#%PAM-1.0

account     [default=bad success=ok user_unknown=ignore] pam_ldap.so debug

auth        sufficient      pam_ldap.so debug
auth        required        pam_deny.so

Basically, this configuration tells PAM to rely on pam_ldap.so to manage user accounts and authentication. As you can see, there is not a lot of information in this file. The Debian documentation explains that this is because pam_ldap.so delegates everything to Name Service Switch. The debug keywords are used for verbosity, and can safely be removed.

NSS

The NSS is provided by the libnss-ldap package. It is a daemon that holds the LDAP configuration and caches the requests to the LDAP.

You can configure your ldap URI, your search DN and your bind credentials in /etc/nslcd.conf:

...
uri ldap://ldap.mydomain.tld

base ou=Users,dc=mydomain,dc=tld

binddn cn=admin,dc=mydomain,dc=tld
bindpw MyVerySecretPassphrase
...

SSHD

On debian Buster, enabling LDAP on it has a side effect: SSH sessions will try to authenticate against the LDAP via PAM, unless you switch UsePAM to no in /etc/ssh/sshd_config.

Debug your installation

To debug this installation, let's launch all those services manually and make them verbose:

Check the system authentication logs:

sudo tail --follow /var/log/auth.log | grep pam_ldap

Launch opensmtpd in verbose mode:

sudo systemctl stop opensmtpd
sudo /usr/sbin/smtpd -dv

Launch the NSS daemon in verbose mode:

sudo systemctl stop nslcd
sudo nslcd --debug

Check what is going on with your LDAP server:

sudo tail --follow /var/log/syslog | grep slapd