17 Followers
·
Follow

Image for post
Image for post
CC TEKNISKA MUSEET

I have a home network that contains a mixture of devices, some of which that receive a static IP address such as the printer, and some of which receive a dynamic IP address such as mobile phones and tablets.

The home router is setup to give every device with a static IP address a host name, such as “printer.home” or “nas.home”, making it easy to access the device’s UI (if it has one). However, the router isn’t capable of assigning host names to devices with a dynamic IP address.

For the most part this isn’t an issue, but every once in a while I do need to access the mobile phone or tablet via the browser or similar. This means having to lookup the IP address of the device in the router, which in turns means I have to login to it and navigate through various screens. …


Image for post
Image for post
FUSE structure CC-BY-SA 3.0 Wikimedia Commons

Proxmox’ LXC containers do not have the device created automatically. A quick way of doing that is by adding the following two lines to the container's configuration on the host node (in ):

lxc.autodev: 1
lxc.hook.autodev: sh -c "mknod -m 0666 ${LXC_ROOTFS_MOUNT}/dev/fuse c 10 229"

I’m using “sh -c” directly rather than a separate script, so that this configuration is migrated to other nodes in the cluster.

As a note, it should already be in the by default, so doesn't need to be added again.

Caveat as mentioned by Fabian (Proxmox staff):

If you absolutely have to, I would suggest establishing the FUSE mount on the Proxmox host and then using a bindmountpoint (e.g. “mp0: /path/on/host,mp=/path/in/container”) to make it available in the container. If you establish the FUSE mounts inside the container, you will run into problems (lxc-freeze is not compatible with FUSE which means no snapshots and no suspend backup, you need to change all sorts of containment settings which lessens security, ..). …


Image for post
Image for post
GnuTLS Logo by Claus Schrammel

Due to the SSL POODLE vulnerability, it is best to remove support for the outdated SSLv3 protocol. As OpenLDAP with GnuTLS is a beast of its own, here’s the quick change to remove SSLv3 support:

cat > nossl.ldif <<EOF
dn: cn=config
changetype: modify
add: olcTLSCipherSuite
olcTLSCipherSuite: SECURE256:-VERS-SSL3.0
EOFldapmodify -Y EXTERNAL -H ldapi:/// -f nossl.ldif

And we’re done! Obviously, if you already have olcTLSCipgerSuite, then use “replace” instead of “add”.

A quick test:

~# gnutls-cli-debug -p 636 127.0.0.1
Resolving '127.0.0.1'...
Connecting to '127.0.0.1:636'...
Checking for SSL 3.0 support... no
Checking whether %COMPAT is required... no
Checking for TLS 1.0 support... yes
Checking for TLS 1.1 support... yes
Checking fallback from TLS 1.1 to... N/A
Checking for TLS 1.2 support... yes

About

Mike Green

I keep servers happy, and they keep me happy.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store