Archive for the ‘Linux’ Category

Autoconfig for mail clients

Saturday, January 6th, 2024

Whenever I have to configure an newly-installed email client I remember one of the long-running topics on my task-list was to setup autoconfiguration for email clients. It’s one of those things one does occasionally (with one’s own domain) so it always seems quicker to set up manually and “get back to it another time”.

The use dates back to fairly early in Thunderbird, and quite a number of mail clients now utilise the same autoconf method.

As it turns out the original author/developer started the IETF RFC publishing process a couple ago as draft-bucksch-autoconfig.

The current mail-client autoconf service is documented well by Mailbox.org. It includes the most information in one place.

The mailbox.org document references Ben Bucksh’s authoritative Thunderbird autoconfig documentation (which, unsurprisingly, makes up the majority of his draft RFC).

It appears that Microsoft has used a different DNS host (and/or SRV record), but the same configuration file, which the mailbox.org document covers should you wish to include Microsoft mail clients.

Basically:
* create a website autoconfig.${DOMAIN}
* get a TLS certificate (if preferred)
* create an xml config file, config-v1.1.xml to be saved in the website and referenced as, eg, https://autoconfig.example.com/mail/config-v1.1.xml
* Add CNAME/SRV records for Microsoft clients, as below.
* test by setting up a new account on an existing or new email client, and use the wizard/autoconfiguration.

DNS records for Microsoft clients:

CNAME:
autodiscover CNAME example.org.
SRV:
_autodiscover._tcp SRV 0 0 443 example.org.

A further step would be to configure calendar clients, which appear to reference RFC6764 as a means for autoconfigure; further investigation for another day!

Mikrotik upgrade to v6.49 and RANCID

Thursday, December 30th, 2021

RANCID is software for backing up network device configuration. Mikrotik is a low-power/low-end networking vendor that is supported by RANCID.

RANCID has worked fine prior to v6.49 code, but a code change in Mikrotik v6.49 firmware breaks the RANCID backup. This issue also apparently exists in Mikrotik OS v7.1. The below URLs reference RANCID problems following the upgrade:

https://www.mail-archive.com/rancid-discuss@www.shrubbery.net/msg00170.html
https://forum.mikrotik.com/viewtopic.php?t=179450

The below URL incorporates a (minor) patch to RANCID that fixes the issue (it basically tells the router to use dumb-terminal mode on login). This patch is not incorporated in RANCID at the time of speaking (current latest is v3.13).

https://github.com/haussli/rancid/commit/fef0b6ec166ae2892e8fc6e6a3d0f2de82379c29

I can’t see this being incorporated into a RANCID package for Ubuntu (or one for Debian) before it is fixed upstream (in the RANCID code), so the fix is currently a hack: a manual edit of the respective file.

Ubuntu 18.04 upgrade

Saturday, December 28th, 2019

The LTS upgrade from Ubuntu 16.04 to 18.04 has largely gone smoothly.

Once again there are problems on the VNC side (logging in remotely, using VNC), particularly useful when accessing the server from an Mac (OSX) machine, where you “share screen…” with the Linux server. However, it appears that the upgrade to Ubuntu 18.04 probably changes the default desktop back to gdm3, which still appears not to support the VNC setup well according to the below:

https://askubuntu.com/questions/1033274/ubuntu-18-04-connect-to-login-screen-over-vnc/

Running the below command, and selecting to use lightdm as the desktop manager will get things back working again.

dpkg-reconfigure lightdm

It appears this changes the following symlink:

root@shuttle:/etc/systemd/system/multi-user.target.wants# ls -l /etc/systemd/system/display-manager.service
lrwxrwxrwx 1 root root 35 Dec 26 21:44 /etc/systemd/system/display-manager.service -> /lib/systemd/system/lightdm.service

Ubuntu 16.04 upgrade

Friday, December 30th, 2016

This holiday saw me upgrade a home server from Ubuntu 14.04 to 16.04. I completed a similar upgrade on another machine recently, but this one has an ‘occasional use’ desktop GUI. The thing that I needed to bear in mind is that Ubuntu 16.04 (like Centos 7 and above) uses systemd instead of System V init or upstart, which affects numerous things (like logging, service restart, etc).

I find that staying behind the curve for upgrades, particularly where it is a must work machine, saves a fair amount of grief. Although I invariably have to track down problems, by the time I get around to an upgrade there tend to be other people who have found (and worked-around) similar issues. This means I can cherry-pick the preferred fix (rather than having to use the horrible hack someone has documented, or track down the real problem/fix).

During this upgrade, after rebooting the screen remained blank. After finding the machine was actually on the network, I tracked it down to this problem:
http://askubuntu.com/questions/792129/16-04-boot-stops-at-a-start-job-is-running-for-hold-until-boot-process-finish

Switching from the gdm3 desktop manager to lightdm fixed this issue; X usage is minimal so features are of minimal interest, as long as it works!

To get x11vnc (the common/standard desktop-agnostic Ubuntu VNC server for X) to start in 16.04 (and later), with systemd, you need the following:
https://help.ubuntu.com/community/VNC/Servers#Have_x11vnc_start_automatically_via_systemd_in_any_environment_.28Vivid.2B-.29

Following the instructions does not seem to cause VNC to start. There must be a better way, but the brute-force reboot caused
it to start a process on port 5900.

The side effect of switching away from gdm3 is that my VNC server configuration no longer functions … more work to do! By way of a reminder, the reason for VNC server is so that the user can connect to do admin tasks without having to physically connect KVM (keyboard/video/mouse) to the server. As OSX is the usual client, integration using Zeroconf (Avahi) makes a lot of difference!

To get Avahi notifying about the service, add the below config to a file (eg, rfb.service) to the /etc/avahi/services/ directory:

———-
<?xml version=”1.0″ standalone=’no’?><!–*-nxml-*–>
<!DOCTYPE service-group SYSTEM “avahi-service.dtd”>
<service-group>
<name replace-wildcards=”yes”>%h</name>
<service>
<type>_rfb._tcp</type>
<port>5900</port>
</service>
</service-group>

The above was shamelessly taken from holyarmy.org – why re-invent the wheel?

Let’s hope that other things haven’t boken, although TimeMachine integration breakage tends to happen on OSX upgrades!

Linux server integration with Apple OSX (client)

Sunday, September 26th, 2010

Last weekend I finally got round to trying an AFP server on Linux and, aside from a few minor issues, things went well.

First of all, I’d like to say credit (and kudos) where it’s due – I used Matthias Kretschmann’s documentation of his experience as a guide for this work. It is great and easy-to-follow documentation (with pictures), so my additions serve to provide updated information as of 2010 and a couple of other scenarios.

My brother has a linux machine that he uses as a CIFS fileserver (for Windows & Mac/OSX) and a destination for Time Machine backups from his Apple Mac, amongst other things. He prefers to use a GUI to manage the machine.

The best available Linux solutions for these seem to be:

  • Samba (well – that’s already running)
  • Netatalk (for AFP filesharing – Time Machine backups are apparently more stable on Apple protocols)
  • x11vnc (VNC access to the X console)
  • Avahi (for Zeroconf/Bonjour)

A VNC server was chosen to view the X console because one is built into OSX (10.5 Leopard and after), so no additional software is required. If you wanted to do something similar from a Windows computer you could use an RDP server on the Linux machine (but I have not tried this).

The first step was upgrading the machine to Ubuntu Linux 10.4 – the latest LTS (long-term stable) release. The big benefit of this Ubuntu version over others is that the binary version of Netatalk in the repositories works with OSX.

Previous versions of Netatalk needed to be compiled with OpenSSL which had an incompatible licence (meaning that binaies of Netatalk could not be shipped with SSL support). This used to mean that if you needed to support OSX clients then you needed to recompile Netatalk .. which made non-SSL-capable binaries fairly pointless. This version uses GnuTLS libraries which allow SSL-capable binaries to be shipped legally. This saves a chunk of pain!

Additionally, Ubuntu 10.4 contains VNC server that works with the X console (display :0) without a user needing to be logged in – something that the old Xvnc Xserver used to be able to do on older versions of XF86/X11 (which didn’t work with the X11.org Xservers in the previous LTS release).

Finally, Avahi brings the AFP and VNC services to Apple mac (OSX) clients in an easy way, using Zeroconf/Bonjour.

The other oddity to be aware of is around server naming. Most services use the server’s hostname when advertising the services/protocols. This is normally fine. However, it seems that the OSX client (Finder) won’t allow a CIFS server (Samba on Linux) and an AFP server (Netatalk on Linux + Avahi for server advertisement) to be displayed – the CIFS server is not displayed.

The work-around I decided to use was to append “-afp” to the AFP servername. An alternative may have been to add a config to Avahi for the SMB server, but I didn’t try this (partly because the only visible difference between the two would then have been the icon).

Enough of the waffle – lets get down to it.

The following were the changes I needed to make to the default configs for Netatalk:

/etc/netatalk/AppleVolumes.default:

/data/timemachine/machines/     “Timemachine-backups” options:tm,upriv,usedots

Please read the Netatalk documentation for a description of the options, but “tm” makes the share time-machine compatible, “upriv” makes it use AFP3 (for additional features?), and “usedots” ensures that any dot-files (filenames or directory names that begin with a . and are deemed ‘hidden files’ in unix) keep their name rather than the “.” being percent-escaped.

The only change from the default for the afpd config file is so that the afp service has a different hostname. I’ve left the default (normally commented out in the config file, as shown here) in to demonstrate that it’s only the servername that is changed:

/etc/netatalk/afpd.conf

# default:
# – -transall -uamlist uams_dhx.so,uams_dhx2.so -nosavepassword
server01-afp -transall -uamlist uams_dhx.so,uams_dhx2.so -nosavepassword

You also need to ensure that the CNID_METAD service is started along with the AFP service. You need to change that service from “no” to “yes”, and that’s the only change required in the startup config:

/etc/default/netatalk

ATALKD_RUN=no
PAPD_RUN=no
CNID_METAD_RUN=yes
AFPD_RUN=yes
TIMELORD_RUN=no
A2BOOT_RUN=no

If you want to use any of the other services provided by Netatalk (such as Apple printing using PAPD, Appletalk using ATALKD, etc) then please see the Netatalk documentation for further details.

The AFP server can now be accessed, but to make it more user-friendly you should try to get it to show up in OSX’s Finder; this requires Zeroconf, as provided by Avahi.

Avahi required very little to provide visibility of the AFP service – just adding the following description file (note the “name” part has “-afp” appended to the hostname, so the service is advertised as server01-afp. If this isn’t wanted, just remove the -afp in the service name):

/etc/avahi/services/afpd.service

<?xml version=”1.0″ standalone=’no’?><!–*-nxml-*–>
<!DOCTYPE service-group SYSTEM “avahi-service.dtd”>
<service-group>
<name replace-wildcards=”yes”>%h-afp</name>
<service>
<type>_afpovertcp._tcp</type>
<port>548</port>
</service>
<service>
<type>_device-info._tcp</type>
<port>0</port>
<txt-record>model=Xserve</txt-record>
</service>
</service-group>

No restart is needed – Avahi (as configured in Ubuntu 10.4) picks this up immediately and advertises it.

You should now be able to connect to the AFP server through the OSX client Finder.

Finally I needed a VNC server that would allow someone to connect to the X server after bootup (before anyone has logged into it). x11vnc seems to be the best solution for this. It also has SSL support and the ability to authenticate with unix passwords (which I didn’t use in this initial test), and avahi support for zeroconf (which I did).

All that was required was to have the x11vnc server start when gdm starts. The x11vnc documentation covered this fairly concisely, and here is an example:

/etc/gdm/Init/Default (at the bottom before exit 0)

#UNIXPW_DISABLE_SSL=1
#UNIXPW_DISABLE_LOCALHOST=1
#x11vnc -o /var/log/x11vnc.log -unixpw -forever -bg
x11vnc -rfbauth /etc/x11vnc/x11vnc-passwd -o /var/log/x11vnc.log -forever -bg -avahi

You also need to create a VNC password for the above to work; that was done by:

x11vnc -storepasswd /etc/x11vnc/x11vnc-passwd

Given the time I would try to use SSL and probably unix password, as this would mean encrypted details and users just needing to know their login credentials which can be changed (rather than a more static shared password). Whether this is an option would depend on the “Screen Sharing” VNC client capability in OSX though. This is probably something for an update (or follow-up).