Beside the official OpenVPN documentation there’s a vast number of howtos and guides out there, that’ll tell you how to set up an OpenVPN server. Unfortunately, most of these use a tunneling setup including some sort of router and packet filter. If you want to transport non-IP based traffic and can accept the increased broadcast overhead and poor scalability, you need to setup an OpenVPN bridge.
If you run into this error:
# sshuttle -r user@remotehost -v 192.168.0.0/24 Starting sshuttle proxy. Listening on ('127.0.0.1', 12300). firewall manager ready. c : connecting to server... user@remotehost's password: s: latency control setting = True Traceback (most recent call last): File "<string>", line 1, in <module> File "assembler.py", line 26, in <module> File "server.py", line 168, in main File "server.py", line 68, in list_routes File "server.py", line 47, in _list_routes File "ssubprocess.py", line 606, in __init__ File "ssubprocess.py", line 1117, in _execute_child OSError: [Errno 2] No such file or directory c : fatal: server died with error code 1
the culprit is simply the missing netstat program on the target host. sshuttle tries to fork a netstat process without checking if netstat is installed on the target host in the first place.
On a Fedora host netstat comes with the
yum install net-tools
To quickly convert a pdf file to dxf, there’s a neat little tool called pstoedit. It’s part of Fedora’s standard repository and can be installed via yum
# yum install pstoedit
To convert a file named
$ pstoedit -f "dxf: -ctl -mm" Drawing.pdf Drawing%d.dxf
Installing the latest EagleCAD on Fedora 19 is a bit tricky. The Linux version requires libssl and libcrypto (which is thankfully mentioned right on the download page), unfortunately an older version which is no longer shipped by Fedora (Version 1.0.1 of openssl was released in March 2012).
As a (very dirty) workaround, you can just create a symlink to the current version of the shared object:
# ln -s -T /usr/lib/libcrypto.so /usr/lib/libcrypto.so.1.0.0 # ln -s -T /usr/lib/libssl.so /usr/lib/libssl.so.1.0.0
Statically mounting remote filesystems via
/etc/fstab can be quite impractical on mobile devices such as notebooks that are frequently used in different network environments where the share is not always available. To take care of this, there’s a great tool called autofs that let’s you mount remote filesystems on demand.
Let’s assume, there’s an NFS server running in our network that exports a certain directory:
$ showmount -e Server Export list for Server: /data Client
To install and enable the
autofs daemon, run:
# yum install autofs [...] # systemctl enable autofs.service # systemctl start autofs.service
As soon as you try to access the remote filesystem, it should get automagically mounted:
# ls -lh /net/Server/data/ [...]
Note that the subdirectory for the host isn’t created until you access it. You can also use so-called direct maps, that can’t be changed on the fly but require a HUP signal to refresh.
To use a direct map, edit
/etc/auto.master and include the following line:
[...] /- /etc/auto.data [...]
/etc/auto.data with the following content:
/data -soft,rw,exec,intr Server:/data
The options should be quite self-explanatory. For a more comprehensive list, have a look at the autofs manpage.
Many applications rely on a fully qualified domain name and won’t work properly or even fail to start without one. For example, even if your hostname is correctly set up, apache won’t start with the default configuration on Fedora 19 if your DNS server cannot resolve the hostname:
AH00557: httpd: apr_sockaddr_info_get() failed for HostName AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1. Set the 'ServerName' directive globally to suppress this message
Since Fedora 19,
nss-myhostname is no longer a separate package but part of the
systemd package. To enable the plugin, open
/etc/nsswitch.conf with you favourite editor and add myhostname to the line starting with
[...] hosts: files dns myhostname [...]
Staring with Fedora 18, the hostname is longer set it
/etc/sysconfig/network but in
/etc/hostname. To manipulate the hostname there’s a small tool named
hostnamectl which is part of Fedora’s
The following table (taken from the Fedora 18 Release Notes) shows a few basic
hostnamectl commands to set or change a host’s name:
|hostnamectl set-hostname fedorasystem --pretty||Set pretty hostname.|
|hostnamectl set-hostname fedorasystem.example.org --static||Set static hostname.|
|hostnamectl set-hostname fedora-dhcp-client.example.org --transient||Set transient hostname.|
|hostnamectl set-hostname fedorasystem.example.org||Without arguments, hostnamectl will apply to all hostname types.|
|hostnamectl status||Show current hostname settings|
See also hostnamectl manpage.
The Arudino IDE Support wiki page at the RepRap wiki also contains a paragraph on how to flash the bootloader onto the Gen7 board with avrdude. It suggest to write the fuses first, the flash the hex file onto the microcontroller and lock the bootloader afterwards. While there’s nothing wrong with that, it can be done in a single command:
$ avrdude -pm1284p -cstk500 -P/dev/ttyUSB0 \ -U lock:w:0x3F:m \ -U flash:w:bootloader-1284P-20MHz.hex \ -U lfuse:w:0xf7:m \ -U hfuse:w:0xdc:m \ -U efuse:w:0xfc:m \ -U lock:w:0x0F:m
Of course, the parameters regarding the processor and the programmer port may be different.
The actual bootloader hex files can be found in the Gen7 Arudino IDE Support package. Probably the easiest way to get it is to clone Traumflug‘s Gen7 git repository
$ git clone https://github.com/Traumflug/Generation_7_Electronics.git
The hex files can be found in:
Generation_7_Electronics/arduino support/Gen7 Arduino IDE Support/Gen7/bootloaders/Gen7/
Make sure to choose the right one for your microcontroller and clock speed. The fuses for the different microcontrollers are listed in
Generation_7_Electronics/arduino support/Gen7 Arduino IDE Support/Gen7/boards.txt