For redundancy I am keeping the same PGP private key on multiple OpenPGP smart cards. Sadly, GnuPG does not provide a way to manage multiple smart cards for the same private key stub. Therefore, the management for the smart cards must be done manually. (This text does not cover creating multiple smart cards with the same device. Outline: I’m running the keytocard command multiple times on different smart cards.)
After importing the smart card on a device, the private key stubs are kept int the directory
~/.gnupg/private-keys-v1.d
To see which file belongs to which private (sub-)key, run
gpg --with-keygrip -K
Then move the files belonging to the smart card to backup locations, for example
cd ~/.gnupg/private-keys-v1.d mv AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.key \ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.key.card1
Repeat this for all private keys stored on your smart card.
After that, unplug the first smart card and plug in the second smart card. Run
gpg --edit-card fetch
Then run gpg –with-keygrip -K again and copy the newly created stub files files to new locations:
cd ~/.gnupg/private-keys-v1.d
mv AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.key \
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.key.card2
Now you can copy the .card1 or card2 files over the original key file and by that switch the smart card. You can write a short bash script that automatically copies the correct key file. Example:
#!/bin/bash
touch ~/.gnupg/sc-toggle-status
SC=$(cat ~/.gnupg/sc-toggle-status)
if [ "$SC" == "card1" ]; then
echo "card2" > .gnupg/sc-toggle-status
find ~/.gnupg/private-keys-v1.d -name "*.card2" | while read f; do cp "$f" "${f%.card2}"; done
echo "Switching to SmartCard 2"
else
echo "card1" > .gnupg/sc-toggle-status
find ~/.gnupg/private-keys-v1.d -name "*.card1" | while read f; do cp "$f" "${f%.card1}"; done
echo "Switching to SmartCard 1"
fi
Recently, I started to set up a Debian Buster based router with IPv6 prefix delegation and two /64 subnets. One subnet is used for desktop clients, the other serves as a demilitarized zone (DMZ) for servers. The Debian router is located behind Fritz.Box home router, which serves as the DSL modem and forwards all external ports to the Debian router. Of course, traditional IPv4 with NAT is also configured. I’m using a dynamic DNS service to access the IPv6 addresses in the DMZ from the Internet. It took me quite some time to figure everything out, therefore I want to share my findings. Of course, this requires that your ISP provides you with more than just one /64 subnet. My ISP provides a /56.
The following diagram illustrates the setup, including interface names on the router:
Regarding IPv4, enp1s0 has the address 192.168.0.2/24, enp2s0 has 192.168.1.1/24 and enp3s0 has 192.168.2.1/24.
First, I had to enable prefix delegation in my Fritz.Box. Coming from the IPv4 NAT world this was something new.
Also configure the /etc/network/interfaces like this:
source /etc/network/interfaces.d/*
auto lo
iface lo inet loopback
allow-hotplug enp1s0
iface enp1s0 inet dhcp
iface enp1s0 inet6 auto
# Important to accept delegated prefixes
post-up sysctl -w net.ipv6.conf.enp1s0.accept_ra=2
allow-hotplug enp2s0
iface enp2s0 inet static
address 192.168.1.1
network 192.168.1.0
netmask 255.255.255.0
allow-hotplug enp3s0
iface enp3s0 inet static
address 192.168.2.1
network 192.168.2.0
netmask 255.255.255.0
Now when connecting enp1s0, the delegated prefixes will automatically be set to the internal facing interfaces. The internal interfaces will receive the addresses $PREFIX::1.
Next, I’m using Dnsmasq on the internal interfaces to provide DNS and IPv6 router advertisements. Add the following lines to the /etc/dnsmasq.conf
To manage inbound and outbound traffic between the different network segments. As is common, the green zone only allows outbound traffic, while the DMZ allows inbound traffic to specified hosts. The following configuration demonstrates how to allow inbound IPv6 traffic to specific hosts. The rule can be extended to specific ports as well. To restore Iptables during boot, I’m using the iptables-persistent package. My /etc/iptables/rules.v4 and /etc/iptables/rules.v6 contain the following lines:
# /etc/iptables/rules.v4
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [81:8253]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i enp2s0 -j ACCEPT
-A INPUT -i enp3s0 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A FORWARD -i enp2s0 -j ACCEPT
-A FORWARD -i enp3s0 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
COMMIT
*nat
:PREROUTING ACCEPT [44:2803]
:INPUT ACCEPT [23:1484]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [24:1535]
-A POSTROUTING -o enp1s0 -j MASQUERADE
COMMIT
# /etc/iptables/rules.v6
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [175:15496]
-A INPUT -p ipv6-icmp -j ACCEPT
-A INPUT -s fe80::/10 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i enp2s0 -j ACCEPT
-A INPUT -i enp3s0 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A FORWARD -i enp2s0 -j ACCEPT
-A FORWARD -i enp3s0 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -d ::2/::ffff:ffff:ffff:ffff -o enp2s0 -p tcp -j ACCEPT
COMMIT
Notice the rule -A FORWARD -d ::2/::ffff:ffff:ffff:ffff -o enp2s0 -p tcp -j ACCEPT. This allows accessing the host in the DMZ from the internet. Now we need to take care that the server in the DMZ always gets the $PREFIX::3 address. This can be done by setting a token with ip. To do this every time the interface is being activated, for example on boot, add the following lines to the /etc/network/interfaces configuration of the server in the DMZ:
iface enp0s31f6 inet6 auto
pre-up /sbin/ip token set ::2 dev enp0s31f6
To publish the IPv6 address of the server on freedns.afraid.org, I’m using the following crontab line (replace $TOKEN with your private token):
* * * * * (IP=$(ip -6 a list dev enp0s31f6 | grep global | awk '{print $2}' | sed 's/\/64//') && wget --no-check-certificate -O - "https://freedns.afraid.org/dynamic/update.php?$TOKEN&address=$IP" >> /tmp/freedns_$HOSTNAME.log 2>&1)
I hope I did not forget any important part. Feel free to ping me if your setup according to this post does not work.
This is an attempt to build a small, lightweight, cheap, diy spectrometer. This was a part of the MINT Girls Regensburg project in 2015 [1]. The spectrometer was designed to work on a Watterott StarterKit Roboter V2 [2]. The robot can connected to a PC via bluetooth. A Python program can be used to remotely control the robot and spectrometer.
All required .stl-files and source code is published under the MIT license on Github [3]. The page about the TSL1402R on Arduino Playground [4] was used as an inspiration.
The spectrometer itself (without Arduino) can be build for less than 40 €.
Spectrometer mounted to robot
List of required parts
1x Black drinking straw
black tape
3D Printer (e.g. black PLA)
printable parts (.stl files)
4x M2,5 x 5mm screws + nuts
4x M2,5 x 10mm screws + nuts
2x M4 x 40mm screws + nuts
1x TSL1402R
4x white LEDs
1x perfboard
wires, pin cables, hit shrink tube, etc
1x Arduino
1x diffraction grating 1000 lines / mm (cheap source [5])
1x 2N7000 MOSFET
Circuits
TSL1402R on perfboard
Cut out a 30 x 11 mm piece from the perfboard. Solder the TSL1402R onto it and drill to holes into the corners. The holes should be 25 mm apart. The corners will be used to screw the perfboard onto the angled chip holder.
Solder cables to the TSL1402R like shown in Figure 9 of the datasheet [6] (serial connection). Basically connect pin 13 to 10 and 4 to 8.
Then connect the cables to the arduino.
Description
Arduino
TSL1402R
Supply voltage +5V
+5V Pin
Pin 1 (VDD)
Ground
Ground
Pins 5 (GND) and 12 (GND)
Signal in
Pin 6
Pin 2 (SI1)
Clock
Pin 2
Pin 3 (CLK)
Analog out
Pin A3
Pins 4 (AO1) and 8 (AO2)
The white LEDs can be turned on and off with a 2N7000. Connect Pin 7 of the Arduino with the Gate of the 2N7000. The four (parallel) LEDs can be connected to the same voltage source as the Arduino. Make sure to place a fitting resistor between the source and LEDs.
Case
All required parts for the case can be 3D printed, preferably in black. Additionally you need a (black) drinking straw and (black) tape.
After printing all parts, screw the perfboard onto the chip mount, and fixate the chip mount into the bottom of the case. The position of the chip mount can be adjusted to the left and right.
Cut a small rectangular piece from the optical grating and glue (?) it into the grating mount. One screw holds the grating mount to the front panel, the second screw allows for a few degrees of rotation in order to align the grating to the TSL1402R.
Use the 2 screw holes at the bottom of the front panel to fasten it to the bottom of the case.
Use tape to fix the black drinking straw to the front panel. Make sure that the straw is well aligned with the forward facing opening.
Spectrometer assembly
Additionally you can glue 4 white LEDs into the holes at both sides of the front panel. Make sure that they focus on a point beyond the drinking straw.
Use a bright light source at the end of the straw to align the TSL1402R and the diffraction grating. After you’re finished with the alignment use the two M4 screw to fixate the case cover. Black tape can be used to seal all slits.
Software
Write the RoboterRemoteControl software into your Arduino. If necessary change the pin layout in the configuration section at the beginning of the file.
The Python3 program qtMissionControl can be used to obtain and print simple readouts from the spectrometer. It requires the libraries PyQt4, numpy and matplotlib. The serial port and baudrate have to be set in line 10 and 11 of the source code.
Here is a small python program a friend and I wrote to map and visualize the structure of websites. It is licensed with the BSD license. The programs opens all links in the start address and recursivly searches through all following links. The crawling process may take a long time for more than 1 or 2 recursions. This may cause a lot of traffic for a website, therefore please contact the site’s admin before you run the program.
I created this image from two photos taken by Mariner 10 in 1975. They seem to be taken with a UV filter. All Mariner 10 images are accessible here: http://pdsimg.jpl.nasa.gov/data/mr10-m-iss-2-edr-pv0.x/. As those images are created by NASA, they are in public domain. Sadly I do not remember which frames exactly I used.
Venus in UV light – CC-BY-SA
While trying to decipher the image file format, I stumbled upon a fine program, written by Piotr Masek, to view Mariner images: http://petermasek.tripod.com/mariner.html. With his “Mariner 10 Image Browser and Reconstructor” you can easily browse through the mve files and save them as .bmp files.
The frames mve_004.011 to mve_004.031 cover venus with a very high resolution and as a project for the future I want to create a panorama view with them.
Update: I created an enhanced version of the image: