This is day 5 of "Inside the Ultimaker 3", Developer mode & Linux/Systemd   -     Other days: Day 1 - GCode Day 2 - Remote access part 1 Day 3 - Remote access part 2 Day 4 - Electronics   -     Today we will take a short look at developer mode. Why? Because I want to make it clear what it does before misconceptions happen.   DEVELOPER MODE - ACTIVATED! Developer mode can be activated from the {SYSTEM}->{Maintenance}->{Diagnostics}->{Developer mode}. Activating this will restart your machine. The reason for this is that it makes it easier for the rest of the code. The rest of the code can just assume that whatever the developer mode switch was on startup, that is what it is during the rest of the time the machine is on.   -     Why did we add a {developer mode} switch, why is it off by default? Well. This is the most important bit. Developer mode makes you machine insecure!. With this mode on, some safety mechanisms are disabled, and remote login is enabled. This means you do not just open the machine for yourself. You potentially also open up the machine for hackers on your local network. So take extreme care with this. If you do not know what you are doing, developer mode is NOT needed.   What does it do? First off, and most importantly. It activate the ssh server. This server allows for remote login trough the network. Linux users will be very familiar with this. Note that you can completely mess up your system with this. Which is why I'm not giving too much information on how to use this right now. As you can access, delete, change any file on the printer. Secondly, it changes the main menu so it always shows the IP address on the printer. We are doing so much with so many printers at the office, that a quick look at the IP address is extremely useful. Next up, it when an error/warning happens, next to the normal message that you get, you get the internal developer message as well. This can provide more information, or confuse you even more.   Inside the printer - Linux Now, we will get nerdy here. So unless you are a Linux nerd, the rest here will sound like voodoo. To start off with some basics. We are running:   A custom image, based on Debian stable (jessie)
We are using systemd. Some Linux people love to hate this. We love it.
If we don't need it, it is most likely not installed.
Most of our own code runs in Python3. So python3 is available on the system.
apt-get is available, but if you run apt-get update you will run out of disk space. This is due to the fact that the root partition is not big enough to contain the huge package list from debian. Run mount /dev/mmcblk0p3 /var/lib/apt/ first. You could also resize your root partition. But that is a bit harder.
    Linux - systemd First off. I love systemd. It makes so many things easier. We are using it for a few main things:   Starting up the system
Bringing down the system for a system update
    Linux - systemd - Starting up Our linux system starts up with systemd. Systemd is some fancy piece of software that handles all kinds of startup and stop action, as well as some more things. Systemd does this by the means of services. You can read a lot about this online. So I'll just go into the very basics. Our own services are defined in:   /etc/systemd/system   And we have a whole bunch of files there that start with "griffin". Most simple example, we have the file:   /etc/systemd/system/griffin.nfc.service   This file handles the NFC service. The NFC service is the part of the system that talks with the NFC hardware to talk with the (optional) NFC tags in spools. The rest of the system has (almost) no knowledge of NFC. I've seperated concerns like that. If you are on the system, you can just read it with cat, as it's a normal text file. It will show you how this service is started, and what it depends on. As for example, the nfc service depends on the printer service to run before it can do it's thing. The reason for this is, it needs to monitor the printer service, as the printer service knows when a material change is happening. And that's when the NFC service needs to do it's thing. So the NFC service listens to the printer service.   -     Now, to start/stop a service we can use systemctl start griffin.nfc.service or systemctl stop griffin.nfc.service. But you will most likely cause problems if you stop indivitual services if you have no clue what you are doing.   Linux - systemd - Logging All these services become really interresting once you add the logging. Systemd adds logging for us as well. But, as added advantage over the "classic" Linux logging, we can filter in this logging. A really common (almost muscle memory) command that we use a lot is:   journalctl -fu griffin.printer   This looks at the logging of just the printer service, and "follows" this logging. Which means that the process you just started won't exit and that every new log message that is added will be directly shown on your screen. I quite often have this running during debugging of issues. There are quite a few cool things you can do with journalctl, other examples:   #Only show the log from this bootjournalctl -b 0#Show the log from the previous bootjournalctl -b -1#Show the last 1000 log lines from the printer servicejournalctl -n 1000 -u griffin.printer     Linux - systemd - System update When we want to do a system update, we have a bit of a problem. As we are running on this system. So we need to update ourselves, while on the move. Once again, systemd really helps us here. We have a special service that we can start, called "update.rootfs.service". This service is intended to run on it's own, without anything else. Systemd as a function for this called "isolate". The isolate function means only that service runs, and it's dependencies. Our update service has no dependencies, so that means everything else is brought down once we isolate that service.   -     When the update.rootfs.service is isolate, we know the rest of the system is not running, and it is safe to update those files. You can check /usr/lib/systemupdate/ for details on how this update process works. It uses rsync, which means only the changed files will be copied over on a system update. Meaning that the amount of writes to disk is actually quite limited, and the chance of the system no longer starting up if the power shuts off during an update is really low. Note, this isolating of the update.rootfs.service is done AFTER signature verification. The full update process also checks if the firmware update file is signed by our private key. To prevent man-in-the-middle-attacks on system updates.   Closing words I understand if this was really really really technical and nerdy. But, if you are toying with the UM3 system, and getting your hands dirty. This explains a few really basic things. Tomorrow I will go into Active Leveling, as I think that's really interesting subject.   -       -     Disclaimer: Any information presented here could be wrong. I did my best to proof read everything, but it could conflict with the actual behavior of the printer.