Raspberry Pi Setup

A few notes on how I set up new raspi systems, of which I am using quite a few for random home automation or toy things.

Prepping the SD card

  • Install “Lite” version of Raspberry Pi OS
  • This should have created one FAT formatted partition that Windows/Mac can access, this is the boot partition
  • Create file “ssh.txt” on boot partition to enable ssh right away, otherwise need to attach a screen for first login
  • If newer raspi and wifi should be used, create file “wpa_supplicant.conf” on boot partition (docs)
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
country=<Insert 2 letter ISO 3166-1 country code here>

 ssid="<Name of your wireless LAN>"
 psk="<Password for your wireless LAN>"

Initial Setup

  • Startup raspi, find IP in DHCP server or try direct ssh to host “raspberrypi” and cross fingers that something somewhere worked right (I think Unifi DHCP server automatically using DHCP provided hostname for DNS? Or is this some MDNS magic? No idea, never looked into it.)
  • Log in with username “pi”, default password “raspberry”
  • sudo raspi-config
    • set network -> hostname
    • set localization -> timezone
    • exit without reboot, it’s not necessary now
  • sudo su -
    • sudo adduser kapet
    • sudo adduser kapet adm
    • sudo adduser kapet sudo
      • and more groups as necessary: dialout, cdrom, audio, video, plugdev, games, input, netdev, spi, i2c, gpio
    • Copy /etc/sudoers.d/010_pi-nopasswd for kapet and update it accordingly
    • reboot
  • Log in as “kapet”
  • sudo su -
    • disable login to the pi account: usermod -e1 -L pi
    • enable longrunning and at-boot started scripts for kapet: loginctl enable-linger kapet
    • apt update
    • apt dist-upgrade
    • apt install lsof tcpdump
    • set the NTP server in /etc/systemd/timesyncd.conf
    • reboot

Other Potential Setup

  • set up basic X11: apt install raspberrypi-ui-mods
  • disable bluetooth on pi3: add dtoverlay=pi3-disable-bt to /boot/config.txt
  • when using any GPU to framebuffer magic like raspi2fb for a local LCD display remember to give the GPU enough memory through raspi-config, the minimum amount is not sufficient


A Surprisingly Useful Tool

20x magnifying stereo microscope, with a common ruler in its fangs.

Based on a recommendation from a coworker I bought a simple stereo microscope for around 30 Euro a while ago. I believe the manufacturers idea is that kids look at insects or little rocks with this (it actually comes with a few tiny splinters of different rocks), but this thing turned out to be extremely useful for several of the electronics stuff I’ve done lately.

For example I’ve used it to check my work after etching a PCB or soldering it. The magnification of 20x turned out to be perfect – it’s significantly better than my eyes but still “real” enough that I can interact with the object using small tools or a soldering bit.

I found having two occulars is not magically improving what I can see, but it certainly makes it less stressful to look through it for a long time. The magnified image shows about 8mm of object width.

In a recent case I was struggling with an Arduino Nano, which was connected to a Raspberry Pi, and just did not want to work if the host rebooted while it was plugged in the USB port. All I got were errors like this in the logfile:

May 23 20:32:28 raspberrypi kernel: [    3.707998] usb 1-1.3: new full-speed USB device number 4 using dwc_otg
May 23 20:32:28 raspberrypi kernel: [    3.807985] usb 1-1.3: device descriptor read/64, error -32
May 23 20:32:28 raspberrypi kernel: [    4.028021] usb 1-1.3: device descriptor read/64, error -32
May 23 20:32:28 raspberrypi kernel: [    4.257989] usb 1-1.3: new full-speed USB device number 5 using dwc_otg         
May 23 20:32:28 raspberrypi kernel: [    4.357989] usb 1-1.3: device descriptor read/64, error -32
May 23 20:32:28 raspberrypi kernel: [    4.577988] usb 1-1.3: device descriptor read/64, error -32
May 23 20:32:28 raspberrypi kernel: [    4.698153] usb 1-1-port3: attempt power cycle
May 23 20:32:28 raspberrypi kernel: [    5.358060] usb 1-1.3: new full-speed USB device number 6 using dwc_otg
May 23 20:32:28 raspberrypi kernel: [    5.818026] usb 1-1.3: device not accepting address 6, error -32
May 23 20:32:28 raspberrypi kernel: [    5.918003] usb 1-1.3: new full-speed USB device number 7 using dwc_otg
May 23 20:32:28 raspberrypi kernel: [    6.357982] usb 1-1.3: device not accepting address 7, error -32
May 23 20:32:28 raspberrypi kernel: [    6.358192] usb 1-1-port3: unable to enumerate USB device

Turns out the problem is not with the USB driver in the Linux kernel, but instead it’s a hardware bug in the Nano: The FTDI serial chip’s “TEST” pin was left unconnected. This way it “floats” after a power cycle and reliably prevented prober USB device enumerating. Ugh. I realized this is the problem after a lengthy search and finally stumbling over this issue in the FHEM wiki.

So here it goes, on the bottom side of the Arduino Nano I need to connect two freaking small SMD pins with each other, so TEST is reliably pulled to ground. I can hardly see those pins properly!

Perfect situation to use the microscope: Put a tiny blob of solder on the very tip of the soldering iron, veeeery slowly direct it to the right pins, and done!

With this the Nano gets connected properly whenever then Raspberry Pi reboots. 🙂

Microscope set up to allow viewing the bottom side of the Arduino Nano.
Solder blob connecting TEST and AGND pins.


Hello Noteblog

Started this Blog to have a place to dump random notes that other people might find useful and so I can find it again later. 🙂


Kerberos, AFS and Batch Systems

(This is an overview I wrote in 2004. I would suspect that a lot of the technology is no longer relevant, but actually this article got still occasional hits on my old homepage so I’m migrating it just in case it’s still useful for some people.)


Kerberos is a system for securely authenticating users in an unsecure network environment. It was developed in the 1980s at the MIT as part of the famous project Athena. During the 1990s Kerberos V5 was standardized in RFC 1510 and became widely used, especially after Microsoft decided to base Windows 2000 security on it. Within Kerberos, each user has a Ticket Granting Ticket (TGT) which can be used to acquire dedicated service-tickets. These service-tickets finally are used to authenticate a user to that service.

AFS (the “Andrew File System”) was started at the Carnegie-Mellon University as a research project. By using a slightly modified Kerberos V4 system they built a secure network filesystem which allows several data-storing servers and complex access control lists. Today AFS is used all over the world, especially by Universities and other research institutions. From the Kerberos point of view, AFS is just a service. AFS itself requires the user to own a valid Kerberos ticket for the service “AFS”, this is often called the “AFS-Token”.

A Batch System is needed for controlling resource usage of special machines like a supercomputer or some compute servers. Users just define what their jobs need (e.g. the number of CPUs), the Batch System decides if and when the user will get these resources. It then takes care of starting (and probably killing) the job, finally some accounting information about the job is saved for accounting or statistics. There are several commercial and non-commercial Batch Systems available these days, two important open source systems are Torque/OpenPBS and Sun’s Grid Engine.

This article is about the problems which arise, when these technologies are used together: Imagine a user submits a job which uses files from his home-directory in AFS. This requires the Batch System to make sure that the job has the users AFS-Token while running or the job would not be able to access the files. Making these files readable by anyone would allow the Batch System to not care about AFS, but this is not an option because of security considerations. Another problem is the limited lifetime of the AFS-Token, it has to be prolonged or renewed to allow the job access AFS continuously.

More information:

Kaserver / Kerberos V4 and AFS-Tokens

The Kaserver is a modified Kerberos V4 server used by the original AFS setup. It has some special features and speaks an additional network protocol (“Rx”) used only by AFS utilities. Its possible to use a Kerberos V4 server instead of the Kaserver (Using MIT’s Kerberos Server with AFS). The normal lifetime of an AFS-Token is configured per user on the server, usually its about 25 hours. The Token is isolated against the rest of the system in a Process Authentication Group (PAG) called structure which is identified by two unique group IDs.

Renewal of an AFS-Token

One possibility to provide a long lasting job with a token is to regain the token from time to time. The process doing this usually needs some knowledge about the users password though, either by asking him during job submission or by requiring him to store it somewhere.

One tool for this task is the “Password Storage and Retrieval System” (PSR), which uses asymmetric cryptography to securely store the users password encrypted in his AFS space. When a job needs to acquire a new token, the password gets decrypted and is used to simply request a new token. The secret key needed to decrypt the password is only stored on the machine that runs the job. If the user changes his password and updates the encrypted storage too, the new password is automatically used on the next renewal.

Another way to store the password is to use a “SRVTAB” file. Such a file is normally used to store a server key but it can also be used to store the key of a user. The stored key is not the plaintext password but some kind of hash. This way the password is not revealed, but be aware: Concerning Kerberos, the hash can be used just like the password. So when a job needs to acquire a new token, the hash can simply be used. You can find a description of this technology here: UMich: “How to run long lived jobs with AFS” Some quick hints to be used with KTH Kerberos V4: Create the SRVTAB like this: ksrvutil -f mysrvtab -c add where is the name of your AFS cell. Enter your username when prompted for “Name:”, the name of your AFS cell in uppercase for “Realm:” and just press enter for “Instance:” and “Version Number:”. It will then ask a password twice, enter your normal AFS password. The created file “mysrvtab” can be used like this: kauth -n myname -f mysrvtab bash where myname is your
username. kauth will run the given command (here: bash) and repeatedly renew the AFS-Token by using the secret from mysrvtab.

Prolongation of an AFS-Token

A completely different approach to extending the lifetime of AFS-Tokens is to prolong them, extend their lifetime without acquiring a new one.

To do this one has to extract the Token from the current environment and decrypt it with the AFS specific Kerberos service key (known only by the Kerberos server and the AFS fileservers). Its now possible to put a new timestamp into the Token, thereby extending its lifetime. After encrypting it with the service key again and putting it back into the users environment, the user has a Token with an extended lifetime. If this process is repeated regularly, the Token never expires.

To my knowledge this way was first gone at CERN in the first half of
the 1990s, they created the programs GetToken, SetToken and forge. These programs became the base of CERN’s “Authenticated Remote Control” (ARC) system, and some time later Codine and LoadLeveler evolved with support for these tools. (Codine is today known as Sun GridEngine, which still contains support for this method.)

A reimplementation of this method can be found in Mike Bechers OpenPBS module extension.

I did just another reimplementation, which does not rely on OpenAFS but uses only Kerberos and “krbafs”, found on any Fedora Core 1 machine.

Kerberos V5 and AFS-Tokens

Kerberos V5 brought some new features, renewable TGT-tickets being the most notable with regard to this article. Such a ticket can be renewed via kinit -R without the need to enter the password again. During a renewal, the kinit command contacts the Kerberos server and asks if the renewal is acceptable. This makes it possible to inhibit further usage of a stolen TGT by e.g. disabling the account on the server. As another security measure, a renewable ticket not only contains the usual (short) lifetime specification, but also features a (long) “renewable lifetime” that declares an upper limit for ticket renewal. Usually the normal lifetime is about a day, while the renewable lifetime can last for months.

Creating AFS-Tokens out of Thin Air

A completely different way to provide jobs with AFS-Tokens is to fake them. This is easy if you know the service key of the AFS service. (Remember: AFS is a Kerberos service, the AFS-Token is just a Kerberos V4 service ticket. Therefore it has a well known structure and is encrypted with the AFS’ service key.) An implementation of this method is available as GSSKLOG, a tool which uses the GSS-API to authenticate a client to the server, eventually giving back a faked AFS-Token if authentication succeeded.

Batch Systems: Required Steps for AFS-Integration

A complete solution would be to include full Kerberos and AFS support into the Batch System. But this would probably require considerable changes in network communication and internal structures, so some simpler way would be better.

When a job is submitted (e.g. qsub)

  • Kerberos V4 with Renewal: Ask the user for his password or check for some prepared storage. Probably attach some information on it to the job.
  • Kerberos V4 with Prolongation: Extract the users Token from the current PAG on the submit host and attach it to the job.
  • Kerberos V5: Forward the TGT along with the job.
  • Fake Tokens: The Batch System must become 100% sure about the users identity.

While the job is queued

  • Kerberos V4: Do nothing.
  • Kerberos V5: Renew the TGT repeatedly.
  • Fake Tokens: Do nothing.

When the job is started

  • Kerberos V4 with Renewal: Instantiate a PAG. Let Kerberos create a new TGT and a new AFS-Token.
  • Kerberos V4 with Prolongation: Instantiate a PAG. Prolong the AFS-Token and insert it into the PAG.
  • Kerberos V5: Instantiate a PAG. Let Kerberos create an AFS-Token (based on the TGT).
  • Fake Tokens: Instantiate a PAG. Create a fake token and insert it into the PAG.

While the job is running

  • Kerberos V4 with Renewal: Create a new TGT and a new AFS-Token repeatedly inside the PAG.
  • Kerberos V4 with Prolongation: Repeatedly prolong the AFS-Token and insert it into the PAG.
  • Kerberos V5: Renew the TGT repeatedly inside the PAG, let Kerberos create an AFS-Token each time.
  • Fake Tokens: Repeatedly create a new fake token and insert it into the PAG.

When the job has finished

  • Kerberos V4: Destroy all local knowledge about the users password and close the PAG.
  • Kerberos V5: Close the PAG.
  • Fake Tokens: Close the PAG.

To sum it up, a Batch System that wishes to support AFS has – at least be able to:

  • call an external program on the submitting host when a job is submitted
  • call an external program regularly while a job is queued
  • allow to start processes by using an external program (a PAG-shell)
  • run an external “shepher” program together with the users process OR call an external program regularly from an own “shepher” process
  • pass some information along with the job and make this information available to the external programs

Not all described mechanisms need all these hooks though.


  • MIT Longjobs: A patched version of OpenPBS which includes some Kerberos support to allow Kerberos authentication and long running job which access AFS.
  • Kerberos on Wall Street: Paper about the Kerberos V4 to V5 migration of Morgan Stanley, includes some remarks about AFS.
  • Globus and AFS

(C)opyright by Karsten Petersen <> in 2004