Chain's computar projects

Installing and setting up connman

So far I’ve been connecting to wifi using wpa_supplicant and a shell script, but I wanted something more flexible and easier to use. Networkmanager is the obvious choice, but I wanted to try something else, and more lightweight(if possible). So I’ve decided to go ahead and try connman which is a Networkmanager alternative designed by intel and intended for mobile and embedded solutions. At this point it’s also full-featured enough that it can be used on the desktop.

Installation

doas xbps-install -S connman cmst

I decided to install connman along with a graphical network management utility(cmst), and an ncurses based network configurator, unfortunately connman-ncurses crashes all the time, and even segfaults on some actions.

So I decided to install ncman instead. I’ve found the most up to date fork.

Building and installing ncman

First we make a directory for storing the source:

mkdir -p ~/src/ncman
cd ~/src/ncman

Then pull the latest source:

git clone https://github.com/milisarge/ncman.git build

Now we have to fix the source, since ncman was built with -Wall (all warning stop the build process), and there’s function used that’s been deprecated.
Open ~/src/ncman/build/src/ncurses_utils.c in your favourite editor and change line 46 from:

vwprintw(win_footer, msg, args);

to:

vw_printw(win_footer, msg, args);

Install necessary dependancies:

doas xbps-install -S meson ninja cmake dbus-devel json-c-devel ncurses-devel

Build and install ncman:

meson setup build
ninja
doas ninja install

Configuration

To prevent dns overrides by connmand we create /etc/sv/connmand/conf with the following content:

OPTS="--nodnsproxy"

Next we create /etc/connman/main.conf with the following contents:

[General]
AllowHostnameUpdates=false
PreferredTechnologies=ethernet,wifi
SingleConnectedTechnology=true

These three config options have the following effects:

  • By default, ConnMan changes the transient hostname on a per network basis. The first option turns off that behaviour.

  • By default ConnMan does not prefer ethernet over wireless, which can lead to it deciding to stick with a slow wireless network even when ethernet is available. The second option fixes that.

  • ConnMan allows you to be connected to both ethernet and wireless at the same time. I prefer to have only one active connection at any given time.

Enabling Connman

First we need to disable dhcpcd(Connman has built in dhcp) and wpa_supplicant:

doas rm /var/service/dhcpcd 
doas rm /var/service/wpa_supplicant

Wpa_supplicant service wasn’t even enabled on my system, but I’ve included that for completeness sake.

Next we enable Connman:

doas ln -s /etc/sv/connmand /var/service/

Check if the service is running:

doas sv status /var/service/connmand⏎
run: /var/service/connmand: (pid 6969) 1s

Final steps

Add user to the network group

doas usermod -a -G network chain

Modifying dbus policies according to this post might be necessary, but it worked for me without this step.

After reloging or rebooting connman should be working.

Network connections can now be controlled with connmanctl(lowest level), ncman, or cmst.

connman-ncurses was last updated 7 years ago, and it already crashed on me when the wrong passphrase was provided. I might update this post if I decide to switch to a more up to date fork.

Edit: Yes, turns out I had the update this post to include the steps necessary to build and install ncman manually.

1 Like

I am curious what kind of flexibility you were looking for that you could not do from the terminal. The only time I found myself using NetworkManager was on my Fedora work laptop when I had to change connections from WiFi to Ethernet with DHCP, to Ethernet but with a static IP, to WiFi again, then to WiFi Guest and turning on OpenVPN and so on.

I could have done it from the terminal (and at some point I switched to nmcli after I switched from Plasma to swaywm), but kept using NM because it was there. In all honesty, I wouldn’t go back to it. Well, nowadays I don’t find myself needing to switch connections as often and if I need any changes, I mostly use ip commands (because that’s what the Void docs present - not sure if they actually recommend it, but those were in the examples, of course I could easily add other tools on my system, but I prefer minimalism).

I agree with you on minimalism - in fact that’s why I chose connman, but I think that I was just a bit worried about ending up in a hotel room without access to the internet and having problems making wpa_supplicant work. I wanted to have access to something easier to use just in case I need it. Connman seems like a good compromise.

In all honesty, I had a better time with wpa_supplicant and wpa_passphrase than I did with NM / nmcli. I never used connman, so I can’t comment on it. In case I ever forget how to use them and I don’t have access to internet, I have a video of Mental Outlaw downloaded on my phone on how to set up wifi.

And because of some things I had problems with, I always remember that wpa_supplicant may connect to wifi, but wlan0 may not automatically request an address via dhcp, so I just run dhcpcd -b wlan0. I don’t know why it would not request an IP by itself, but for startup of my void router, I have a runit dhcpcd-wlan0 service file (that is running with -B instead of -b). It kind of makes sense, since wifi is a layer2 protocol, but still.

We’ll see how it goes. I mean in the worst case scenario I can easily revert this since I’ve already documented the installation here.

I guess I’ve lost some based points for not using wpa_supplicant directly :joy:

I’m still working on the WM and all the surrounding stuff, which means patching stuff as I go. I’ve made good progress, but some new issues have cropped up.
Turns out that there are three big packages that I use that aren’t available in Void repositories. Those being: Librewolf(my conversion script works at least), Ungoogled chromium, Libreoffice-still.
Ungoogled-chromium doesn’t officially provide debian packages now, which was supposed to be temporary, but it’s been like that since june. At least I’ve found unofficial deb packages.
Libreoffice-still - here official deb packages are provided at least.

The thing is that xdeb that I’ve been using to convert the Librewolf package is discouraged by Void developers because it did wreck peoples systems in the past. I can fix that even if it happens(which I think is unlikely nowadays). Xbps-src also allows(since yesterday) to convert deb packages in a more controlled manner. Both browsers and libreoffice-still is provided by nixpkgs, and it’s a nice system, but it’s not for me. I want stuff to be properly installed on my system, and not in local user’s directory with some symlink mumbo-jumbo. I could also leverage xbps-src to build all three from source, but it’s a wasted effort since I don’t intend to contribute it back to Void(and the only reason for that is because I have no intention of starting a github account).
The easiest solution is to use nixpkgs, deb conversion is the middle ground, and building my own xbps packages is the most proper way to do this, but also the most complicated one.

Right now I’ll probably stick with using xdeb to convert what I need. I’ve also been explicitly told that deb extraction support was added to increase the number of proprietary packages available in the repos, and not to increase the number of packages by using it convert open-source stuff. Which, I think, is a shame, because the low number of available packages is the main reason people don’t go for Void Linux. Usually I don’t care about the popularity of Linux, but in this case I feel it’s kind of a chicken and egg problem: there aren’t enough maintainers because there aren’t enough users to recruit from, and there aren’t enough users because there aren’t enough packages(ie. maintainers).

Brave was also notably absent from void repos last I checked. For me, libreoffice’s absence on arm is quite the hit. I had to xbps-src it a few times, but many times it’s been broken. Now it is broken again. I’d rather change my workflow than keep build LO. And I wouldn’t mind going back to x86, but I tend to live frugally, I’d rather not change my PC.

There is also rpm converter for xbps, fedora might have the packages.

On x86, I never found myself not finding what software I needed and even more amazing what things void ships in default repos for servers, like grafana, prometheus and more.

nix-pkg may look like symlink mambo jambo, but it has its reasons and it’s a fantastic pkg man.

I’m not questioning its reasons for doing it that way, or even that it’s a fantastic package manager(I’ve said that myself to other people), but it’s not something I’d be particularly comfortable with - like I said - I feel that it’s not for me. One thing to note about nixpkgs is that they do support aarch64, and they do provide libreoffice builds for that arch. I’d be surprised if it didn’t work on Raspberry Pi, and I can imagine that building libreoffice from source on rpi is more of a pain than it would be on my 12 core Xeon.

Do you perhaps remember the name of that converter? I can’t seem to find it.

1 Like

I’ve spent the last three days trying to make an old electron app work on Void. It relies on lots of old libraries and stuff, but there’s no AppImage available(only linux binaries in a tarball), so I had to build my own.

Jeez, what a journey it was…
Building from source didn’t pan out. It tries to pull stuff from github using git:// protocol(which isn’t supported anymore, so the connections are refused), which pulls old stuff that uses it as well to pull some other stuff. So to correct that I’d have to create a github account, fork all those repos and fix them. And I have absolutely no intention of creating a github account.
I built the AppImage in an Ubuntu 18.04 VM from binaries, after tracing libraries, and solving crashes(starting with problems with harfbuzz caused by an old version of electron) it finally started working there, but when I moved it over to 20.04 it segfaulted. Finally I managed to solve that, but then it didn’t work as it should because it relies on an old version of vlc.

So I’ve found an alternative piece of software, and although this one did build from source I still had to correct the makefiles and it’s built differently - not using electron, but QtWeb. That means that it also has lots of dependencies and I couldn’t make it work on void without installing a whole bunch of Qt libraries there(which I didn’t want), and wasn’t exactly designed the way I was comfortable with.

So I decided to give plan A one more shot.
Vlc is problematic because it brings a whole load of dependencies on its own. At first I started looking through packages but it quickly turned into a nightmare, and then I figured it out: maybe there’s an AppImage of that old version of VLC somewhere? And turns out that there was! It’s slightly newer than what I wanted to use, but still works fine, so I extracted the vlc AppImage and integrated its contents with what I was working on, wrote an AppRun as a shell script that sets the $PATH and $LD_PATH variables to make sure that the stuff included in the AppImage is used, and voila! It started working.
When I moved it over to the Void on my laptop I was amazed that it worked!

Before building the package everything inside takes 797MB of space(so it’s easy to imagine how many libraries are included), after building the AppImage that goes down to 285MB(thanks to gzip compression). Still not light, but manageable.
I’m happy that it works, and that I don’t have to pollute my system with lots of stuff that I wouldn’t use otherwise. Now everything is nice and contained! And no flatpacks or snaps were needed! Just fuse!

1 Like

CRON, ANACRON, INCRON, and update monitoring

Ok, so I had to set up cron, anyway, got it working kind of, but then fixed it up. Also I took inspiration from @ThatGuyB 's post mentioning update monitoring, and I think I’ve improved upon it a little bit.

First things first though.

Setting up cron

Void offers several cron implementations to choose from. I decided to go with dcron, which turned out to be the right choice, as it’s a relatively minimal implementation, and yet provides some asynchronous features which I’ve taken advantage of.

First we install dcron and enable its service:

doas xbps-install -Su dcron
doas ln -s /etc/sv/dcron /var/service/

Next we want to add two cronjobs for the root user. Since I’m using ZFS root I’d like to have automatic scrubbing every two weeks. I also want my package database to update every 3 hours.

So we switch to the root account:

doas su

and edit the crontab file:

# crontab -e

to look like so:

# root crontab
# DO NOT EDIT THIS FILE MANUALLY! USE crontab -e INSTEAD

# man 1 crontab for acceptable formats:
#    <minute> <hour> <day> <month> <dow> <tags and command>
#    <@freq> <tags and command>

# SYSTEM DAILY/WEEKLY/... FOLDERS
@hourly         ID=sys-hourly   /usr/sbin/run-cron /etc/cron.hourly
@daily          ID=sys-daily    /usr/sbin/run-cron /etc/cron.daily
@weekly         ID=sys-weekly   /usr/sbin/run-cron /etc/cron.weekly
@monthly        ID=sys-monthly  /usr/sbin/run-cron /etc/cron.monthly

# Crontab modified below this line
* * * * *       ID=sys-3hourly FREQ=3h  /usr/bin/xbps-install -S
* 16-18 * * *   ID=sys-biweekly FREQ=14d /usr/bin/zpool scrub zroot

This setup makes sure that xbps-install -S is run every 3 hours and that our zroot pool is scrubbed between 4 and 6 p.m. every 14 days.

Setting up incron

Incron is a very nifty piece of software! It can execute commands not based on time or frequency(as cron or anacron do), but based on filesystem events. I’ve used it in the past, and I thought that this is a perfect opportunity to use it again!

First we install incron and enable its service:

doas xbps-install -Su incron
doas ln -s /etc/sv/incron /var/service/

Now we edit the incrontab for the local user:

incrontab -e

We want the incrontab file to look like this:

/var/db/xbps/https___*/x86_64-repodata    IN_MODIFY,loopable=true    sleep 1 && pkill -RTMIN+20 dwmblocks
/var/db/xbps/pkgdb-*.plist    IN_MODIFY,loopable=true    sleep 1 && pkill -RTMIN+20 dwmblocks

Please note that the signal specified for the update monitoring block in dwmblocks is 20 in my case. Adjust accordingly.
What the above incrontab directive do is they monitor x86_64-repodata files in all directories beginning with /var/db/xbps/https___, which in practice means that we’re monitoring all the repository databases. The 20 signal will be sent to dwmblocks on IN_MODIFY event, which means that this will occur any time the monitored files are modified(another option is to use IN_ATTRIB), and the loopable=true directive tells it that it shouldn’t fire again until the current event handler has finished.
We’re also monitoring the package list file, as it’ll change once we actually update the system, at which time we want the changes in package list to trigger update block refresh so that the icon indicating available updates will disappear. The pkill command is preceded by sleep 1, so that we wait 1 second before refreshing the block - this is so that if several monitored files are for some reason modified at the same time, the 20 signal will only be sent once(loopable=true directive makes sure of that).

DWMBLOCKS script to tie it all together

Because we’re already monitoring the package databases, we don’t have to refresh the block every 30 seconds(or whatever time you feel like), but we can rely on the 20 signal sent from incron! That means that the script itself can be very simple:

if [ "$(/usr/bin/xbps-install -u --dry-run | /usr/bin/wc -l)" -ne 0 ]; then 
    printf "%s" "⇮"
    exit
fi

In my actual script I’m using this glyph from fontawesome. The above script could be extended to launch a terminal with doas xbps-install -u command on left click, but I decided to omit that, because I want to have more manual control over my updates in case something goes wrong. I just don’t want borked updates to happen and the terminal to close on update completion. It’s also worth noting that because we’re using the --dry-run flag to check for updates, we don’t need to run it as root, because nothing on the system is changed.

So far everything seems to be fine, but I’ll update this post in case I make some changes.

Edit:
Ended up making some changes. We’re monitoring package list file as well, and we’re using xbps-install -u --dry-run instead of xbps-install -Su --dry-run in the dwmblocks script(sync wasn’t performed anyway in dry-run mode, and we’re doing synchronising using cron).


This is a sidenote unrelated to the rest of this post. I’ve found Ungoogled-chromium build for Void! This is a source build, and also there’s a repo, so it’s one problem less!

1 Like

Last time I tried running xbps update, even the dry-run, without root, it wouldn’t actually update the repo db, so notifications never happened, which is why I went the root crontab. Do let me know if it works, the less things I can run as root, the better.

The repo db is updated every three hours using cron(as root). The script launches xbps-install -Su --dry-run to check if there are updates(using the information from repo db). It’s basically the same thing you were doing, but I’m not creating temporary files and I’m not putting the output of that command in a variable but comparing it to 0 directly.

The dwmblocks script works 100%, what I’m not totally sure of yet is if the rest of it will work reliably. I’ve tested it as much as I could, but I’ll know for sure when new updates pop up.

1 Like

Ok, so I’ve made some changes to the post, but it works great now! No matter if the package db is synchronised through cron(which happens every 3 hours) or if I do it manually - if something new is available updates icon will show up in the bar! After installing updates the icon will disappear automatically as well.