A not really technical talk, at least not in terms of details. But Benno, who comes from the FreeBSD side, covers a lot of stuff from the conceptual side. My verdict: Absolutely worth it.
We are used to terminal sessions displayed like any other content, i.e. as a video of some kind. The latter comes with two caveats, though. It uses a lot of bandwidth (compared to the actual terminal session) and is often difficult to read. Because many people do not bother to magnify the terminal either during the actual presentation or as part of the post-processing.
In addition to using the hosted instance, that supports sharing in multiple ways, you can also run your own server via Docker. For all the details, please go to the website.
Although it is not a focal point of my professional live any more, Linux and I share a long common history. My first encounter was with “S.u.S.E. Linux August 1995″ (kernel 1.1.12) in October or November of 1995. Until then I had only played around a bit with MINIX 1.5 on a 80286-based PC. But it had been a bit of a disappointment for me and I never really got into things.
This changed dramatically with Linux. I spent many hours trying to get a setup with X11 (only FVWM2 was available as window manager then) to work. This was not as easy as today. There was no, or very little, support from YaST, the setup tool of SuSE. And one had to be careful with the monitor (CRT of course) configuration. Because too high frequencies could physically damage your monitor. I never used the system to actually perform any work, it was solely for learning.
This changed with SuSE 4.4 and even more so with SuSE 6.1. I do not remember the exact dates, but SuSE 6.1 was installed in late 1997 when I ran my own small company as a “side-project” to my university studies. But since the company was highly successful, I soon used things like HylaFax on Linux and of course also ran my local mail server (sendmail can be a challenge, especially when Google does not exist yet). There even was a dial-in modem for terminal connections.
What I always disliked about SuSE, was that the updates from one version to another never really worked for me. So in about 2002 I finally decided to switch to Debian Woody (3.0). That was again a learning curve, but the
apt packaging system was vastly superior to what I had seen on SuSE before and I never had problems with upgrades. The experience gained then is also quite helpful these days for the Raspberry Pi.
Things continued with CentOS, Fedora, and Ubuntu – with the last two powering my company notebook for a short while back in 2008. But the experience was mixed and I never liked Linux as a general-purpose desktop operating system. I had used it extensively for writing LaTeX documents (using Xfig a lot for diagrams) during my university time. But other than that, for too many Windows (or later Mac) applications I never found a proper replacement.
But for servers Linux is definitely my preferred OS. And especially so because most of the innovations of the last years, like configuration management systems (e.g. Chef, Puppet, Ansible) and containers (e.g. Docker), came to live on Linux.
As mentioned in My WiFi Setup with Ubiquiti Networks UAP-AC-PRO I run the Unify Controller software on a Raspberry Pi 3. There is a ready-made package available for Debian and Ubuntu Linux, that can easily be used for this and I have been doing so for more than a year.
Just a yesterday, though, I broke things by overdoing it a bit with the removal of unneeded software from the Raspberry Pi. Through some “chain” the Unifi Controller had been removed and after re-installation it did not work anymore. Instead I saw a constant CPU utilization of an entire core by Java and also errors in
[2017-12-26 13:07:04,783] <launcher> INFO system - *** Running for the first time, creating identity *** [2017-12-26 13:07:04,791] <launcher> INFO system - UUID: yyyyyyy-yyyy-yyyy-yyyyyy-yyyyyyy [2017-12-26 13:07:04,817] <launcher> INFO system - ====================================================================== [2017-12-26 13:07:04,819] <launcher> INFO system - UniFi 5.6.26 (build atag_5.6.26_10236 - release) is started [2017-12-26 13:07:04,819] <launcher> INFO system - ====================================================================== [2017-12-26 13:07:04,867] <launcher> INFO system - BASE dir:/usr/lib/unifi [2017-12-26 13:07:05,057] <launcher> INFO system - Current System IP: xxx.xxx.xxx.xxx [2017-12-26 13:07:05,059] <launcher> INFO system - Hostname: zzzz [2017-12-26 13:07:05,071] <launcher> INFO system - Valid keystore is missing. Generating one ... [2017-12-26 13:07:05,072] <launcher> INFO system - Generating Certificate[UniFi]... please wait... [2017-12-26 13:08:33,574] <launcher> INFO system - Certificate[UniFi] generated! [2017-12-26 13:08:53,004] <UniFi> ERROR system - [exec] error, rc=1
The last couple of lines were showing up repeatedly, so obviously the system tried to restart over and over again. When you search the Internet for this problem, you will find out that you are not alone. Most solutions address available memory and not all people succeed with the various approaches to increase it (typically by removing memory from graphics and increasing swap space).
What I realized was that most discussions were for older versions and a recurring theme was that things changed between minor versions. So something that had worked for v5.6.19 did not necessarily work for v5.6.22 and vice versa. Also, changes to how Java was dealt with were mentioned quite often. Running Java-based applications on Linux can be somewhat delicate, so I do not blame the folks at Ubiquity Networks for that.
This was when I realized that the JVM on my system had changed. Before the accidental cleanup I had used the Oracle 8 JVM that gets installed via the Debian package
oracle-java8-jdk. So I re-installed the latter and configured it as the default JVM via
sudo apt-get install oracle-java8-jdk sudo update-alternatives --config java
This solved my problems instantly and things are up and running again.
Most people I come across use
tail -f fileName to watch files. The drawback, however, is that for a closer inspection of something I had just seen, I have to abort this and change to some file viewer (where I first need to find again what I want to check). So why not use a single program that can do both things?
less fileName does this for you. What many seem to be unaware of, is that less has a built-in tail mode that can be activated with Shift-F and left with Control-C. Once back in normal view mode again, it is very easy to scroll up a few lines and inspect the interesting part of the file. And once finished, you can just press Shift-F again and are back to tail mode.
While exploring MQTT I had installed the Mosquitto message broker on my Raspberry Pi. However, the version that is in the Debian Wheezy repository is, as of this writing, really old (v0.15). So an upgrade was in order and fortunately the guys from Mosquitto have set up a Debian repo of their own and a description how to use it.
But on my system I then got the following message:
xxx@yyy:/etc/apt/sources.list.d# sudo apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages have been kept back:
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
The general recommendation to solve this is run
sudo apt-get dist-upgradeI did not want to do this for various reasons. So the approach I took instead, was to simply remove the old version with
sudo apt-get remove mosquitto mosquitto-clients and re-install it, then taking the new version from the Mosquitto repo
sudo apt-get install mosquitto mosquitto-clientswhich worked nicely for me.
I have an old machine running Xubuntu 12 and quite like it. But the shutdown from the UI sometimes does not work. One possible consequence is that after the next start the window title bars are gone, as was in my case the widget to switch virtual desktops. To get this fixed a simple
rm -r ~/.cache/sessions/is enough.
When trying to connect to my new Raspberry Pi via SSH, this only worked when done locally. It turned out to be caused by the /ect/hosts file. I had set the hostname using the raspi-config tool, which linked it with the loopback address instead of the real one (192.168.x.x). Changing it to the proper address solved the issue.
Although I was quite sure that I had SE Linux disabled, it was causing connection issues for me. Entering the command
chcon -t samba_share_t /path solved this for me.
If you have created a proper response file and still get this error
Password can’t be null. Enter password:
there is a chance that it is due to a wrong end-of-line character sequence. This usually happens when you initially created the response file on a non-Unix/Linux environment. Convert it using the dos2unix program and you should be fine.