Max Mehl (System administration)

INWX DNS Recordmaster - Manage your DNS nameserver records via files in Git

Thu, 07 Nov 2024 00:00:00 +0000

I own and manage 30+ domains at INWX, a large and professional domain registrar. Although INWX has a somewhat decent web interface, it became a burden for me to keep an overview of each domain’s sometimes dozens of records. Especially when e.g. changing an IP address for more than one domain, it caused multiple error-prone clicks and copy/pastes that couldn’t be reverted in the worst case. This is why I created INWX DNS Recordmaster which I will shortly present here.

If you are an INWX customer, you can use this tool to manage all your DNS records in YAML files. Ideally, you will store these files in a Git repository which you can use to track changes and roll back in case of a mistake. Having one file per domain provides you a number of further advantages:

You can easily copy/paste records from other domains, e.g. for SPF, DKIM or NS records
Overall search/replace of certain values becomes much easier, e.g. of IP addresses
You can prepare larger changes offline and can synchronise once you feel it’s done

INWX DNS Recordmaster takes care of making the required changes of the live records so that it matches the local state. This is done via the INWX API, ensuring that the amount of API calls is minimal.

This even allows you to set up a pipeline that takes care of the synchronisation¹.

Wait, there is more

As written above, I already had a large stack of domains that I previously managed via the web interface. This is why some additional convenience features found their way into the tool.

You can convert all records of an existing and already configured domain at INWX into the file format. This made onboarding my 30+ domains a matter of a few minutes.
On a global or per-domain level, you can ignore certain record types. For example, if you don’t want to touch any NS records, you can configure that. By default, SOA records are ignored. You may even ignore all live records that don’t exist in your local configuration.
Of course, you can make a dry run to see which effects your configuration will have in practice.

Did I miss something to make it more productive for you? Let me know!

Install, use, contribute

You are welcome to install this tool, it’s Free and Open Source Software after all. All you need is Python installed.

One of the tool’s users is the OpenRail Association which manages some of its domains with this program and published its configuration. This is a prime example of how organisation can make the management of records transparent and easy to change at least internally, if not even externally.

While the tool is not perfect, it already is a huge gain for efficiency and stability of my IT operations, and it already proves its capabilities for other users. To reach the remaining 20% to perfection (that will take 80% of the time, as always), you are most welcome to add issues with enhancement proposals, and if possible, also pull requests.

For example, see the workflow file of the OpenRail Association. ↩︎

Seafile Mirror - Simple automatic backup of your Seafile libraries

Fri, 22 Sep 2023 00:00:00 +0000

I have been using Seafile for years to host and synchronise files on my own server. It’s fast and reliable, especially when dealing with a large number and size of files. But making reliable backups of all its files isn’t so trivial. This is because the files are stored in a layout similar to bare Git repositories, and Seafile’s headless tool, seafile-cli, is… suboptimal. So I created what started out as a wrapper for it and ended up as a full-blown tool for automatically synchronising your libraries to a backup location: Seafile Mirror.

My requirements

Of course, you could just take snapshots of the whole server, or copy the raw Seafile data files and import them into a newly created Seafile instance as a disaster recovery, but I want to be able to directly access the current state of the files whenever I need them in case of an emergency.

It was also important for me to have a snapshot, not just another real-time sync of a library. This is because I also want to have a backup in case I (or an attacker) mess up a Seafile library. A real-time sync would immediately fetch that failed state.

I also want to take a snapshot at a configurable interval. Some libraries should be synchronised more often than others. For example, my picture albums do not change as often as my miscellaneous documents, but they use at least 20 times the disk space and therefore network traffic when running a full sync.

Also, the backup service must have read-only access to the files.

A version controlled backup of the backup (i.e. the plain files) wasn’t in scope. I handle this separately by backing up my backup location, which also contains similar backups of other services and machines. For this reason, my current solution does not do incremental backups, even though this may be relevant for other use cases.

The problems

Actually, seafile-cli should have been everything you’d need to fulfill the requirements. But no. It turned out that this tool has a number of fundamental issues:

You can make the host the tool is running on a sync peer. However, it easily leads to sync errors if the user just has read-only permissions to the library.
You can also download a library but then again it may lead to strange sync errors.
It requires a running daemon which crashes irregularly during larger sync tasks or has other issues.
Download/sync intervals cannot be set manually.

The solution

seafile-mirror takes care of all these stumbling blocks:

It downloads/syncs defined libraries in customisable intervals
It de-syncs libaries immediately after they have been downloaded to avoid sync errors
You can force-re-sync a library even if its re-sync interval hasn’t reached yet
Extensive informative and error logging is provided
Of course created with automation in mind so you can run it in cronjobs or systemd triggers
And as explained, it deals with the numerous caveats of seaf-cli and Seafile in general

Full installation and usage documentation can be found in the project repository. Installation is as simple as running pip3 install seafile-mirror, and a sample configuration is provided.

In my setup, I run this application on a headless server with systemd under a separate user account. Therefore the systemd service needs to be set up first. This is also covered in the tool’s documentation. And as an Ansible power user, I also provide an Ansible role that does all the setup and configuration.

Possible next steps

The tool has been running every day since a couple of months without any issues. However, I could imagine a few more features to be helpful for more people:

Support of login tokens: Currently, only user/password auth is supported which is fine for my use-case as it’s just a read-only user. This wouldn’t be hard to fix either, seafile-cli supports it (at least in theory). (#2)
Support of encrypted libraries: Shouldn’t be a big issue, it would require passing the password to the underlying seafile-cli command. (#3)

If you have encountered problems or would like to point out the need for specific features, please feel free to contact me or comment on the Mastodon post. I’d also love to hear if you’ve become a happy user of the tool 😊.

Docker2Caddy - An automatic Reverse Proxy for Docker containers

Mon, 25 Apr 2022 00:00:00 +0000

So you have a number of Docker containers running web services which you would like to expose to the outside? Well, you probably will at least have considered a reverse proxy already. Doing this manually for one, two or even five containers may be feasible, but everything above that will be a PITA for sure. At the FSFE we ran into the same issue with our own distributed container infrastructure at and crafted a neat solution that I would like to present to you in the next few minutes.

The result is Docker2Caddy that provides a workflow in which you can spin up new containers anytime (e.g. via a CI) and the reverse proxy will just do the rest for you magically.

The assumptions

Let’s assume you want to go with reverse proxies to make your web services accessible via ports 80 and 443. There are other possibilities, and in more complex environments there may be already integrated solutions, but for this article we’ll wade in a rather simple environment spun up with docker-compose¹.

Let’s also assume you care about security and go with a rootless installation of Docker. So the daemon will run as an unprivileged user. That’s possible but much more complex than the default rootful installation². Because of this, a few other solutions will not work, we’ll check that later.

Finally, each container shall at least have one separate domain assigned to it for which you obviously want to have a valid certificate, e.g. by Let’s Encrypt.

In the examples below, we have two containers running, each running a webserver listening to port 8080. The first container shall be available via first.com, the second via second.net. The latter shall also be available via www.second.net.

The problems

In the described scenario, there are a number of problem for automating the configuration of the reverse proxy in order to direct a domain to the correct container, starting with container discovery to IPv6 routing to handling offline containers.

The reverse proxy has to be able to discover the currently running containers and ideally monitor for changes regularly so that a newly created container with a new domain is reachable within a short time without manual intervention.

Before Docker2Caddy we have used nginx-proxy combined with acme-companion (formerly known as docker-letsencrypt-nginx-proxy-companion). These are Docker containers that query all containers connected to the bridge Docker network. For this to work, the containers have to run with environment variables indicating the desired domains and local ports that shall be proxied.

In a rootless Docker setup this finally reaches its limits although discovery still works. But already before that we did not like the fact that we had to connect containers to the bridge network upon creation and therefore lost a bit more isolation (which is dubious in Docker anyway).

Now, with rootless, IPv6 was the turning point. Even in rootful Docker setups, IPv6 – a 20+ years old, well defined standard protocol – is a pain in the butt. But with rootless, the FSFE System Hackers team did not manage to get IPv6 working in containers to the degree that we needed. While IPv6 traffic reached the nginx-proxy, it was then treated as IPv4 traffic with the internal Docker IP address. That bits you ultimately if you limit requests based on IP addresses, e.g. for signups or payments. All traffic via IPv6 will be treated as the same internal IPv4 address, therefore triggering the limits regularly.

The easiest solution therefore is to use a reverse proxy running on the host system, not as a Docker container with its severe limitations. While the first intuition lead us to nginx, we decided to go with Caddy. The main advantages we saw are that a virtual host in Caddy is very simple to configure and that TLS certificates are generated and maintained automatically without extra dependencies like certbot.

In this setup, containers would need to open their webserver port to the host. This “public” port has to be unique per host, but the internal port can stay the same, e.g. port 1234 could be mapped to port 8080 inside the container. In Caddy you would then configure the domain first.org to forward to localhost:1234. A more or less identical second example container could then expose the port 5678 to the host, again listen on 8080 internally, and Caddy would redirect second.net and www.second.net to localhost:5678.

But how does Caddy know about the currently running containers and the ports via which they want to receive traffic? And how can we handle containers that are unavailable, for instance because they crashed or have been deleted for good? Docker2Caddy to the rescue!

The solution

I already concluded that Caddy is a suitable reverse proxy for the outlined use case. But in order to be care-free, the configuration has to be generated automatically. For this to work, I wrote a rather simple Python application called Docker2Caddy that is kept running in the background via a systemd service and writes proper logs that are also rotated nicely.

This is how it works internally: it queries (in a configurable interval) the Docker daemon for running containers. For each container it looks for specific labels (that are also configurable), by default proxy.host, proxy.host_alias and proxy.port. If one or multiple containers are found – in our case two – one Caddy configuration file per container is created. This is based on a freely configurable Jinja2 template. If the configuration changed, e.g. by a new host, Caddy will be reloaded and will create a TLS certificate if needed.

But what happens if a container is unavailable? In Docker2Caddy you can configure a grace period. Until this is reached, the Caddy configuration for the container in question is not removed but could forward to a local or remote error page. Only afterwards, the configuration is removed, and Caddy reloaded subsequently.

So, what makes Docker2Caddy special? I am biased but see a number of points:

Simplicity: fundamentally it’s a 188 pure lines of code Python script.
Configurability: albeit it’s simplicity, it’s easy to configure for various needs thanks to the templates and the support for rootless Docker setups.
Adaptability: it should be rather simple to make Docker2Caddy also work for Podman, or even use different reverse proxies. Feel free to extend it before I’ll do it myself someday ;)
Performance: while I did not perform before/after benchmarks, Caddy is blazingly fast and will surely perform better on the host than in a limited Docker container.

If you’re facing the same challenges in your setup, please feel free to try it out. Installation is quite simple and there’s even a minimal Ansible playbook. If you have feedback, I appreciate reading it via comments on Mastodon (see below), email, or, if you have an FSFE account, as a new issue or patch at the main repo.

This is how a very minimal Docker service in the FSFE infrastructure looks like. For Docker2Caddy, only the docker-compose.yml file with its labels is relevant. ↩︎
If you’re interested in setting this up via Ansible, I can recommend the ansible-docker-rootless role which we integrated in our full-blown playbook for the container servers. ↩︎

System Hackers meeting - Lyon edition

Tue, 31 Mar 2020 00:00:00 +0000

For the 4th time, and less than 5 months after the last meeting, the FSFE System Hackers met in person to coordinate their activities, work on complex issues, and exchange know-how. This time, we chose yet another town familiar to one of our team members as venue – Lyon in France. What follows is a report of this gathering that happened shortly before #stayhome became the order of the day.

For those who do not know this less visible but important team: The System Hackers are responsible for the maintenance and development of a large number of services. From the fsfe.org website’s deployment to the mail servers and blogs, from Git to internal services like DNS and monitoring, all these services, virtual machines and physical servers are handled by this friendly group that is always looking forward to welcoming new members.

Interestingly, we have gathered in the same constellation as in the hackathon before, so Albert, Florian, Francesco, Thomas, Vincent and me tackled large and small challenges in the FSFE’s systems. But we have also used the time to exchange knowledge about complex tasks and some interconnected systems. The official part was conducted in the fascinating Astech Fablab, but word has it that Ninkasi, an excellent pub in Lyon, was the actual epicentre of this year’s meeting.

Saturday morning after reviewing open tasks and setting our priorities, we started to share more knowledge about our services to reduce bottlenecks. For this, I drew a few diagrams to explain how we deploy our Docker containers, how our community database interacts with the mail and lists server, and how DNS works at the FSFE.

To also help the non-present system hackers and “future generations”, I’ve added this information to a public wiki page. This could also be the starting point to transfer more internal knowledge to public pages to make maintenance and onboarding easier.

Todo? Done!

Afterwards, we focused on closing tasks that have been open for a longer time:

The DNS has been a big issue for a long time. Over the past months we’ve migrated the source for our nameserver entries from SVN to Git, rewrote our deployment scripts, and eventually upgraded the two very sensitive systems to Debian 10. During the meeting, we came closer to perfection: all Bind configuration cleaned from old entries, uniformly formatted, and now featuring SPF, DMARC and CAA records.
For a better security monitoring of the 100+ mailing lists the FSFE hosts, we’ve finalised the weekly automatic checks for sane and safe settings, and a tool that helps to easily update the internal documentation.
Speaking of monitoring: we did lack proper monitoring of our 20+ hosts for availability, disk usage, TLS certificates, service status and more. While we tried for a longer time to get Prometheus and Grafana doing what we need, we performed a 180° turn: now, there is a Icinga2 installation running that already monitors a few hosts and their services – deployed with Ansible. In the following weeks we will add more hosts and services to the watched targets.
We plan to migrate our user-unfriendly way to share files between groups to Nextcloud, including using some more of the software’s capabilities. During the weekend, we’ve tested the instance thoroughly, and created some more LDAP groups that are automatically transposed to groups in Nextcloud. In the same run, Albert shared some more knowledge about LDAP with Vincent and me, so we get rid of more bottlenecks.

Then, it was time to deal with other urgent issues:

Some of us worked on making our systems more resilient against DDoS attacks. Over the Christmas season, we became a target of an attack. The idea is to come up with solutions that are easy to deploy on all our web services while keeping complexity low. We’ve tested some approaches and will further work on coming up with solutions.
Regarding webservers, we’ve updated the TLS configurations on various services to the recommended settings, and also improved some other settings while touching the configuration files.
We intend to ease people encrypting their emails with GnuPG. That is why we experimented with WKD/WKS and will work on setting up this service. As it requires some interconnection with others services, this will take us some more time unfortunately.
On the maintenance side of things, we have upgraded all servers except one to the latest Debian version, and also updated many of our Docker images and containers to make use of the latest security and stability improvements.
The FSFE hosts a few third party services, and unfortunately they have been running on unmaintained systems. That is why we set up a brand new host for our sister organisation in Latin America so they can eventually migrate, and moved the fossmarks.org website to our automatic CI/CD setup via Drone/Docker.

The next steps and developments

As you can see, we completed and started to tackle a lot of issues again, so it won’t become boring in our team any time soon. However, although we should know better, we intend to “change a running system”!

While the in-person meetings have been highly important and also fun, we are in a state where knowledge and mutual trust are further distributed between the members, the tasks separated more clearly and the systems mostly well documented. So part of our feedback session was the question whether these meetings in the 6-12 month rhythm are still necessary.

Yes, they are, but not more often than once a year. Instead, we would like to try virtual meetings and sprints. Before a sprint session, we would discuss all tasks (basically go through our internal Kan board), plan the challenges, ask for input if necessary, and resolve blockers as early as possible. Then, we would be prepared for a sprint day or afternoon during which everyone can work on their tasks while being able to directly contact other members. All that should happen over a video conference to have a more personal atmosphere.

For the analogue meetings, it was requested to also plan tasks and priorities beforehand together, and focus on tasks that require more people from the group. Also, we want to have more trainings and system introductions like we’ve just had to reduce dependencies on single persons.

All in all, this gathering has been another successful meeting and will set a corner stone for exciting new improvements for both the systems and the team. Thanks to everyone who participated, and a big applause to Vincent who organised the venue and the social activities!

The 3rd FSFE System Hackers hackathon

Tue, 22 Oct 2019 00:00:00 +0000

On 10 and 11 October, the FSFE System Hackers met in person to tackle problems and new features regarding the servers and services the FSFE is running. The team consists of dedicated volunteers who ensure that the community and staff can work effectively. The recent meeting built on the great work of the past 2 years which have been shaped by large personal and technical changes.

The System Hackers are responsible for the maintenance and development of a large number of services. From the fsfe.org website’s deployment to the mail servers and blogs, from Git to internal services like DNS and monitoring, all these services, virtual machines and physical servers are handled by this friendly group that is always looking forward to welcoming new members.

Overview of the FSFE’s services and servers

So in October, six of us met in Cologne. Fittingly, according to a saying in this region, if you do something for the third time, it’s already tradition. So we accomplished this after successful meetings in Berlin (April 2018) and Vienna (March 2019). And although it took place on workdays, it’s been the meeting with the highest participation so far!

Getting. Things. Done!

After the first and second meeting were mostly about getting an overview of historically grown and sparsely documented infrastructure and bringing it into a stable state, we were able to deal with a few more general topics this time. At the same time, we exchanged our knowledge with newly joined team members. Please find the areas we worked on below:

Florian migrated the FSFE Blogs to a new server and thereby also updated the underlying Wordpress to the latest version. This has been a major blocker for several other tasks and our largest security risk. There are still a few things left to do, e.g. creating a theme in line with the FSFE design and some announcement to the community. However, the most complicated part is done!
Altogether, we upgraded a lot of machines to Debian 10, just after we lifted most servers to Debian 9 in March. Some are still missing, but since the migration is rather painless, we can do that during the next months.
We confirmed that the new decentralised backup system setup by myself and based on Borg works fine. This gives us more confidence in our infrastructure.
Thanks to Florian and Albert, we finally got rid of the last 2 services that were not using Let’s Encrypt’s self-renewing certificates.
Vincent and Francesco took care of finishing the migration of all our Docker containers to use the Docker-in-Docker deployment instead of the hacky Ansible playbooks we used initially. This has a few security advantages and enables the next developments for a more resilient Docker infrastructure.
At the moment, all our Docker containers run on one single virtual machine. Although this runs on a Proxmox/Ceph cluster, it’s obviously a single point of failure. However, for a distribution on multiple servers we lack the hardware resources. Nonetheless, we already have concrete plans how to make the Docker setup more resilient as soon as we have more hardware available. Vincent documented this on a wiki page.
On the human side, we made sure that all of us know what’s on the plate for the next weeks and months. We have quite a few open issues collected in our Kanban board, and we quickly went through all of them to sketch the possible next steps and distribute responsibilities.

Started projects in the making

Two days are quite some time and we worked hard to use them as effectively as possible, so some tasks have been started but could not be completed – partly because we just did no have enough time, partly because they require more coordination and in-depth discussion:

As follow-up on a few unpleasant surprises with Mailman’s default values, we figured that it is important to have an automatic overview of the most sensible settings of the 127 (!) mailing lists we host. Vincent started to work on a way to extract this information in a human- and machine-readable format and merge/compare it with the more verbose documentation on the mailing lists we have internally.
Francesco tackled a different weak point we have: monitoring. We lack a tool that informs us immediately about problems in our infrastructure, e.g. defunct core services, full disk drives or expired certificates. Since this is not trivial at all, it requires some more time.
Thomas, maintainer of the FSFE wiki, researched on a way to better organise and distribute the SSH accesses in our team. Right now, we have no comfortable way to add or remove SSH keys on our more than 20 machines. His idea is to use an Ansible playbook to manage these, and thereby also create a shared Ansible inventory which can be used as a submodule for the other playbooks we use in the team so we don’t have to maintain all of them individually if a machine is added, changed or removed.
One of the most ancient physical machines we still run is hosting the SVN service which is only used by one service now: DNS. We started to work on migrating that over to Git and simultaneously improving the error-checking of the DNS configuration. Albert and I will continue with that gradually.
Not on the system hackers meeting itself but two days later, Björn, Albert and I worked on getting a Nextcloud instance running. Caused by our rather special LDAP setup, we had to debug a lot of strange behaviour but finally figured everything out. Now, the last missing blocker is some user/permission setting within our LDAP. As soon as this is finished, we can shut down one more historically grown, customised-hacked and user-unfriendly service.

Overall, the perspective for the System Hackers is better than ever. We are a growing team carried by motivated and skilled volunteers with a shared vision of how the systems should develop. At the same time, we have a lot of public and internal documentation available to make it easy for new people to join us.

I would like to thank Albert, Florian, Francesco, Thomas and Vincent for their participation in this meeting, and them and all other System Hackers for their dedication to keep the FSFE running!

FSFE Planet has been refurbished

Mon, 11 Feb 2019 10:33:11 +0000

If you are reading these lines, you are already accessing the brand-new planet of the FSFE. While Björn, Coordinator of Team Germany, has largely improved the design in late 2017, we tackled many underlying issues this time.

So what has changed under the hood?

The whole system runs in a Docker container now, with all code accessible on our Git. Yes, Docker has drawbacks, but in this case it eases maintenance for our volunteers and makes contributions to design and code very simple.
The old planet ran on a very old Debian server which had issues with modern TLS versions. This basically erased a few blogs from the planet whose webservers do not support older encryption standards.
The design has been improved once more. It now more closely aligns to the design of our main page fsfe.org and feels more natively to use and browse.
Many blogs which were not accessible any more have been removed, and those which redirected to other URLs have been updated accordingly.

So with the migration to the new system you will probably find a few new blogs and unread posts in your RSS feeds now. So please do not be confused about it but look forward to even more useful and interesting bits from the FSFE community!

On this occasion I would like to thank Michael and Vincent for their contributions to the code, and the useful feedback from various people in the FSFE’s community. If you have ideas how to further improve our planet, please open an issue in the Git repository or write an email to us.

splitDL – Downloading huge files from slow and unstable internet connections

Fri, 26 Jun 2015 15:59:03 +0000

Imagine you want install GNU/Linux but your bandwidth won’t let you…

tl;dr: I wrote a rather small Bash script which splits huge files into several smaller ones and downloads them. To ensure the integrity, every small files is being checked for its hashsum and file size.

That’s the problem I was facing in the past days. In the school I’m working at (Moshi Institute of Technology, MIT) I set up a GNU/Linux server to provide services like file sharing, website design (on local servers to avoid the slow internet) and central backups. The ongoing plan is the setup of 5-10 (and later more) new computers with a GNU/Linux OS in contrast to the ancient and non-free WindowsXP installations – project „Linux Classroom“ is officially born.

But to install an operating system on a computer you need an installation medium. In the school a lot of (dubious) WindowsXP installation CD-ROMs are flying around but no current GNU/Linux. In the first world you would just download an .iso file and ~10 minutes later you could start installing it on your computer.

But not here in Tanzania. With download rates of average 10kb/s it needs a hell of a time to download only one image file (not to mention the costs for the internet usage, ~1-3$ per 1GB). And that’s not all: Periodical power cuts cancel ongoing downloads abruptly. Of course you can restart a download but the large file may be already damaged and you loose even more time.

My solution – splitDL

To circumvent this drawback I coded a rather small Bash program called splitDL. With this helper script, one is able to split a huge file into smaller pieces. If during the download the power cuts off and damages the file, one just has to re-download this single small file instead of the huge complete file. To detect whether a small file is unharmed the script creates hashsums of the original huge and the several small files. The script also supports continuation of the download thanks to the great default built-in application wget.

You might now think „BitTorrent (or any other program) is also able to do the same, if not more!“. Yes, but this requires a) the installation of another program and b) a download source which supports this protocol. On the contrary splitDL can handle every HTTP, HTTPS or FTP download.

The downside in the current state is that splitDL requires shell access to the server where the file is saved to be able to split the file and create the necessary hashsums. So in my current situation I use my own virtual server in Germany on which I download the wanted file with high-speed and then use splitDL to prepare the file for the slow download from my server to the Tanzanian school.

The project is of course still in an ongoing phase and only tested in my own environment. Please feel free to have a look at it and download it via my Git instance. I’m always looking forward to feedback. The application is licensed under GPLv3 or later.

Some examples

Server-side

Split the file debian.iso into smaller parts with the default options (MD5 hashsum, 10MB size)

split-dl.sh -m server -f debian.iso

Split the file but use the SHA1 hashsum and split the file into pieces with 50MB.

split-dl.sh -m server -f debian.iso -c sha1sum -s 50M

After one of the commands, a new folder called dl-debian.iso/ will be created. There, the splitted files and a document containing the hashsums and file sizes are located. You just have to move the folder to a web-accessible location on your server.

Client-side

Download the splitted files with the default options.

split-dl.sh -m client -f http://server.tld/dl-debian.iso/

Download the splitted files but use SHA1 hashsum (has to be the same than what was used on the creation process) and override the wget options (default: -nv –show-progress).

split-dl.sh -m client -f http://server.tld/dl-debian.iso/ -c sha1sum -w --limit-date=100k

Current bugs/drawbacks

Currently only single files are possible to split. This will be fixed soon.
Currently the script only works with files in the current directory. This is also only a matter of some lines of code.

I love Taskwarrior, therefore I love Free Software

Sat, 14 Feb 2015 12:05:42 +0000

“It’s Valentine’s day and you’re writing a blog post? Are you nuts?” you might ask. Well, but it’s not only Valentine’s day but also I love Free Software day. This day is proclaimed every year on February 14 by the Free Software Foundation Europe to thank all developers and contributors of Free Software (software you can use for any purpose, which source code you or others can analyze, which can be modified and distributed).

As last year with ZNC, I want to say thank you to a specific project which easies my daily life. As you might know by other blog posts here, organisation of tasks, mails and almost everything else is a very important issue for me. So this year I want to write some lines about Taskwarrior, taskd and Mirakel which enable me to take some free time without thinking of task which I could possibly forget to accomplish later on.

My head is full of ideas and mental To-Do lists and so I’m in need of a handy tool which allows me to write down and organise items at any place and time: At my desk, in bus or train, when I’m offline or abroad. And its important that I don’t have (analog and digital) bits of paper everywhere, so I need a system that syncs all task inputs and outputs. I tried a lot of tools but Taskwarrior was the best so far. It used the well-known „Getting Things Done“ concept with different priorities. Taskwarrior also supports tagging tasks, organising them in projects, due dates, postponing, making tasks dependend on others and much more. And Taskwarrior has a (modifiable) algorhythm that sorts your tasks by urgency levels, so that the most important tasks always are on the top of the list. Even now I just took a glance at what Taskwarrior is able to do!

Someone who loves Taskwarrior as much as I do

“Services and programs that organise tasks aren’t very special!” one might think. But if you prefer sorting tasks digitally, you cannot simply chose a random todo-organising service provider. Most of the tools and services on the market aren’t free and transparent. All input may no longer belong to you, all the gathered information (which is a lot if you think of it!) could be used for targeted ads or worse. You cannot modify the algorhythm to suit your needs. And what happens if the service provider goes bankrupt? All data, all project history and all pending tasks would be lost at once. So using a free (as in freedom), decentralised, maybe self-hosted service is the best idea to organise your tasks decentrally.

But one thing at a time, let’s start from the very basic. You can install Taskwarrior and almost any operating system. After the installation, taskwarrior isn’t much more than a black window with white letters in it. And even when you’re a pro-user, you won’t find much more than white or colourful text on black background – and this is a good thing! I’ve seen no graphical user interface which can handle Taskwarrior’s complexity and the users‘ needs sufficiently (but there are some, feel free to test them!). Nevertheless, it’s quite easy to use Taskwarrior from your terminal:

task add "This is my first task"          # Add your first item
task long                                 # Show all pending tasks
task add "Second VIP task!" pri:H         # Add a task with priority
task add "Third task with tag" +test      # Add a task with a tag
task add "Fourth projected task" pro:Blog # Add a task with a project
task long                                 # Show all pending tasks
task 1 done                               # Mark first task as done (ID = 1)

There are many useful and well understandable guides in the project’s documentation. Most likely you do not need every command but maybe it’s useful to read something about techniques which might help you to organise your tasks your way.

Some useful commands of Taskwarrior using some fish shell features

But Taskwarrior is only for your local computer. What’s if you want to use it when sitting in the bus and don’t want to forget a ToDo item you want to write down at the very moment? Then there’s a handy application for Android called Mirakel. Even the app itself is powerful, but it’s full potential is unleashed when combining it with Taskwarrior. For this, we need a central instance which synchronises the tasks you add or edit on your devices. The Taskwarrior project developed taskd for it which you can easily setup on a server. You can also use Mirakel’s own public taskd server (at least in the past) if you don’t own a server or don’t want to maintain this service.

So if you connect both Taskwarrior and Mirakel to the new taskd server, you can easily share all tasks among them. When marking a task done on your smartphone, it’s marked as done on your home computer some seconds or minutes later if you want to. Security is an important part of taskwarrior as well, so transport encryption is on by default. And if you want, you can also try a web interface or other handy tools and extensions for your server and client which I haven’t tested yet.

Hopefully you now know a bit more about Taskwarrior and Mirakel and the great tools they designed. Of course I do not only want to recommend some software but also use this opportunity to say a big THANK YOU to all the people behind these projects! Thank your for developing the software and making it compatible to each other. Thanks to the various contributors which are writing the important documentation, adding new languages, writing tools and bridges for other usage scenarios and thank you for reacting to bug reports. People like you make Free Software possible!

Yourls URL Shortener for Turpial

Sat, 24 Jan 2015 01:58:32 +0000

Maybe you know Yourls, a pretty cool URL shortener which you can set up on your own server very easily. Link shorteners are nice to have because

you can share long links with short urls and
you can view and organise all links you ever shared (incl. statistics and so on).

There are many alternatives like bit.ly, ur1.ca and so on, but Yourls belongs to YOU and you don’t have to pay attention to ToS changes or the provider’s financial status. AND you can use whichever domain you own, for example in my case it’s s.mehl.mx/blabla.

And maybe you also know Turpial, a Twitter client for GNU/Linux systems (I don’t like Twitter’s web page). Until lately I used Choqok, a KDE optimised client, but there were many things which annoyed me: No image previews, slow development, unconvenient reply behaviour and so on. And hey, why not trying something new? So I started to use Turpial which seems to solve all these critic points. Well, like always I missed some preferences to configure. But since it’s Free Software, one is able to look how the software works and to change it – and to share the improvements which I’ll do in the next step!

Turpial already offers some link shorteners but not Yourls. But we can add it manually. To do so, open the file /usr/lib/python2.7/dist-packages/libturpial/lib/services/url/shortypython/shorty.py as root. Now add the following somewhere between the already existing shorteners

# Yourls
class Yourls(Service):

	def shrink(self, bigurl):
		resp = request('http://YOUR_DOMAIN/yourls-api.php', {'action': 'shorturl', 'format': 'xml', 'url': bigurl, 'signature': 'YOUR_SIGNATURE'})
		returned_data = resp.read()
		matched_re = re.search('(http://YOUR_DOMAIN/[^"]+)', returned_data)
		if matched_re:
			return matched_re.group(1)
		else:
			raise ShortyError('Failed to shrink url')

yourls = Yourls()

Just replace YOUR_DOMAIN and YOUR_SIGNATURE accordingly. The usage of a signature enables you to hide your username and password when sending the shorten requests, like an API key and looks like f51qw35w6 (more about passwordlessAPI). You can retrieve your signature on your Yourls‘ Admin page via Tools.

Then add the new service to the list of shorteners. In the same file search for services = { (on the bottom) and add somewhere in the following list:

'yourls-instance': yourls,

Well, then just restart Turpial, go to Preferences > Services and choose yourls-instance from the list of Short URL services. Congrats, you should be able to short your URLs with Yourls in Turpial now :)

Any problems or improvements? Drop me a message!

Notes:

For me, only hardcoding the signature worked but not the prompt for these data like in some other services stated in the file
Another file worth your attention might be /usr/lib/python2.7/dist-packages/turpial/ui/qt/templates/style.css. There you can change colors, fonts and so on. For example, the Ubuntu font wasn’t installed on my system so I just chose Sans Serif instead.

Sharing is caring – my Git instance

Fri, 28 Nov 2014 17:16:50 +0000

Some days ago I noticed another time that I have far too little knowledge about Git.

„Time to change that!“, I thought and set up my own Git instance and also installed gitweb for better usability.

Upside 1: I can keep track of the many (mainly bash) scripts I wrote in the past and all the changes I will adopt in the future.

Upside 2: You can hopefully benefit from using and reading my code. All code is licensed under GNU GPL v3 so please feel free to use, study, share and improve my work!

Some noteworthy projects I’m (a bit) proud of:

A seminar project with R to analyse over 300.000 SPON news articles whether and which country names appear
Fast download of mixcloud sets without throttle
Easy to use script to delete all meta data from PDF files in a directory
And many more (and even more to come)! Have a look at src.mehl.mx for the whole list

Any questions, ideas or improvements? Please contact me!

Update 26.02.2016

I washed away the quite basic gitweb instance and moved to Gogs. Here’s why and how. Links to the project may have changed because of that (and I’m too lazy to change them here).

Birthday Calendar with ownCloud via CalDAV

Wed, 17 Sep 2014 22:56:46 +0000

Not a big issue in this blog post but an important one. Maybe I can save you some valuable time if you ever look for such a function.

As you know I’m a heavy user of ownCloud and you also might know that synchronisation is a big topic for me. And the third thing you should know that forgetting a good friend’s birthday really su… well, it’s no good style. This almost happened to me some days ago because I couldn’t check it on my Notebook with Thunderbird. My setup looks like this: All contacts (with birthday tags) in ownCloud, and these CardDAV address books are synced with my Android phone and Thunderbird/SOGo-Connector on my notebook, as well as the CalDAV calendars with Lightning.

For Android there are several free software apps which enable the inclusion of birthdays from your contacts into any calendar app. Some calendar apps even can do it theirselves. But for Thunderbird there are only some outdated add-ons. All of them don’t work with TB31 anymore and if you modify the install.rdf-file to make them run anyhow, they’re very buggy or just nonfunctional. And if you look in your ownCloud instance (where contacts‘ birthdays are visible in the calendar tab) for a downloadable/syncable calendar you’ll reach the same conclusion like me: There is none.

But there is!

And I only detected it while digging in some github issue threads. This post contains the rescuing link to a CalDAV/ICS calendar in any ownCloud version (I tested it in 7.0.2). Just modify and use following address in any application which supports CalDAV sync:

http(s)://YOUR-OC-URL/remote.php/caldav/calendars/YOUR-USER/contact_birthdays

And you know what? It works like a charm! No need for external add-ons or apps, no need for manual creation of birthday reminders, no need for apologising for (almost) missed birthdays. I just wonder why ownCloud hasn’t included this in either the webpanel or the documentation. It’s a well-working feature since at least one year, so why not including it officially? And if it’s a calendar technically, then it should also be possible to disable displaying the contacts‘ birthdays in the webpanel calendar app – a still non-existent „feature“.

So next time you have no excuse for forgetting a birthday – except for your ownCloud server’s outage ;)

I love ZNC because #ilovefs

Fri, 14 Feb 2014 05:00:14 +0000

Today is I love Free Software day 2014. Using the slogan „I love Free Software but I love you more“ this day should not only be used to thank our significant others for their love but also to say „thank you“ to people who work hard to ease one’s everyday tasks with the software they develop.

Have you ever been in an IRC channel?

If not, you should try it, it’s a great and easy way of communication and very common.

If yes, then the term „IRC Bouncer“ might be familiar to you. It keeps „you“ online 24/7 in the channel, although your device at home is offline. During this time, your slot in the channel is reserved by your bouncer.

Screenshot of ZNC

In this blog post, I’d like to present ZNC to you, a beautiful piece of Free Software which you can install easily on a server, is highly configurable and consumes only little server resources.

„What the hell should this be for?!“ you’re asking? Well, since I’m presenting ZNC, I can give you a few examples of the mightyness of this software:

Features

If you’re leaving the channel, ZNC can set an individual away status and reply to anyone how’s calling you directly in the channel or in a query that you’re unavailable at the moment
You can add multiple IRC networks with only one account and one port. Similar bouncers like psybnc are unable to do this. You can edit your networks separately, for example with different nicknames or away messages
You don’t want to quit IRC even if you have to because the ongoing discussion is so interesting? No problem with ZNC. ZNC can buffer the channel chat and queries to you, so you can everything if you’re back again. This also helps if you had connection issues and come back a few minutes later – you’ll never miss anything again

Well, these are only the basic functions. Below I added several others which have convinced me to keep using ZNC and nothing else. Of course, it’s Free Software (Apache 2.0 License) and it’s quite actively developed. If you have no server or no time to install something on it, you can also use one of the many ZNC providers for free.

If you like ZNC as much as I do, please consider helping them to improve the software or just donate to keep the very useful wiki alive!

Further cool functions you might find useful:

Administration:

Installation is super-simple: Get the newest version, configure, make and make install. Then execute an configuration script which asks for the most important parameters while explaining them to you. Ready.
Upgrade is very easy. Some days ago I upgraded from 0.2x to 1.2, a large version step. No problem at all, all configuration has been adapted
Multi-user: You can set up an infinite amount of users per server/port, each with several networks.
ZNC has a great webpanel which lets you administer everything. Of course, you can also do this directly in you IRC client if you’re connected

Nerdy stuff:

To protect you from suprises, you can enable modules like fail2ban (to block password bruteforcers), ctcpflood or crypt (to chat encrypted with other znc users without having them to install an extra plugin or client)
You can automatically change your nick if you’re going offline. For example with „username_offline“ you make clear that you’re definitely not available
You can create custom CTCP replies. Try to write /ctcp USERNAME version and you’ll get detailed information about his IRC client. With ZNC, you can simply overwrite the default reply and send something generic instead
You can even get shell access through your IRC client if you enable the function. Dunno what’s the advantage of this but it’s cool, right? ;)

Mounting a SFTP storage in GNU/Linux

Mon, 13 Jan 2014 14:42:01 +0000

This (longer than expected) post explains how to transfer files securely between your device and an external storage. The first part may be useful for you if you only have little knowledge of terms like (S)FTP(S) and want to learn something about widely used technologies. The second part will help you to mount an external storage so you can manage all files as if they are on your local device and the third, fourth and fifth part will concentrate on easing the mounting process by the help of hostnames, Private/Public Keys and a shell script.

This guide will be very detailed and is also (and especially) suited for beginners. Maybe also some advanced users can learn something or give hints for improvements.

Update: With improving Bash skills and more time, I was able to heavily improve the script in the end. Have a look at my Git instance to download the latest version.

But let’s be honest: All in all, this post will show you again, why Free Software, GNU/Linux and Open Standards are great, easy to use and why Windows users are to be pitied.

Short excursus

(Nearly) everybody knows FTP. FTP is a protocol which enables you to transfer files between your device and a remote space. Maybe you want to present your documents or images to visitors of your homepage and simply want to upload these files on your webspace. In most cases this could be done by the use of a seperate program like FileZilla.

So far so good, but there’re several problems. Two of them:

FTP is insecure. Period.
Using an external program (and not your personal file manager) is really annoying if you want to edit the files very often. A realistic example: You have a complicated script running on your website which you’d like to edit in a graphical editor. Using an external client forces you to download the file, open it in your editor, save it and upload it again. Some FTP clients like FileZilla have the functionality to ease this pain in the a**, but trust me: after the twentieth reupload you want to toss your computer away…

Now we know why FTP is insecure. So what alternatives do we have?

There is FTPS – using the FTP protocoll in connection with SSL. Well, that sounds great because, you know, SSL is great to ensure the safety of your online banking and frightens away sniffing script kiddies. Forget that. FTPS is only securing the authentication process, the transfer of all files remains in plain text. So if you upload a sensitive document, it is fairly easy to intercept it on different levels in the uploading/downloading process. There is also the fact that FTPS is horrible to implement, not very compatible, and not very smart designed.

The best alternative in my opinion is SFTP (you are confused by all the abbreviations now? Wait for it, it gets better). SFTP uses a SSH connection to build a safe tunnel between your device and the remote storage. SSH is very smart, widely used and on most servers running a Free operating system it is preinstalled and needs no further configuration. SFTP enforces you to transfer your files fully encrypted through a secure channel.

But how to use it? You can use clients like FileZilla but do you remember the first problem I mentioned? Correct, an external editor is not what suits the needs of someone who wants to work with his files comfortably.

Mounting an external storage with SSH

This sounds more complicated than it really is. The theory behind it is very easy: You mount (link) a remote directory over SSH (a secure channel) in any desired directory on your machine. For instance, you can simply edit all files in /home/user/remote/ with your programs, but finally all changes will happen (nearly) instantly on your remote storage. This even works with watching a video file that is located on the server: Open it like a normal video file in a player like VLC and it behaves like it is locally on your PC (if your internet connection is fast enough, just test it!).

The only prerequisite: You need a server/webspace/storage with full SSH access. Unfortunately many webhosters don’t provide SSH access. If you belong to the unlucky ones, I recommend you to look for alternatives – it is worth it! (below this post, I added a very small list of webhosting providers offering SSH access)

Now we come to the technical part. For this post, following data is used. Most likely, this will look different in your case.

SSH-Server: server1.net
Username on server: client
Home directory of user on server: /home/client
Username local machine: user
Local mount directory: /home/user/remote/server1

On your GNU/Linux, please assure that following programs are installed. Some of them (ssh-askpass, zenity) are only used in step IV and V:

openssh-client, sshfs, ssh-askpass, zenity

Now create a directory in which the remote storage should be mounted in. Don’t worry about the space on your hard disk: This directory is remote and there are only temporary files stored on your local device. In this example I’ll use /home/user/remote/server1. It could also be /fsfe/lol/wtf/nsa/ if this directory would exist.

Now, start a terminal/shell to fill in following commands as a normal user.

ssh -p 22 client@server1.net

If asked for a password, fill in the password of ‚client‚ (the webhoster should have given it to you). If you are now connected to the server1.net, you are just one step away from mounting it. Close the connection or terminal, open it again and type:

sshfs -p 22 client@server1.net: /home/user/remote/server1/ -o follow_symlinks

This command connects to ‚server1.net‚ as the user ‚client‚ using the SSH protocol over the standard port 22. Then it mounts the home directory of ‚client‚ on the local directory ‚/home/user/remote/server1‚ which we created beforehand. Additionally we added the option ‚follow_symlinks‚ so that links of the server work on our local machine as well. If you have a look at /home/user/remote/server1, you should see the exact same content than in the home directory on your server or if you connect via FTP/SFTP. Congratulation! Now play around with it, try to edit, upload and download files.

To unmount (speak: disconnect) the directory, type

fusermount -u /home/user/remote/server1

Now you mount the home directory of ‚client‘. If you want to mount another directory on the server (e.g. /home/client/exchange), use this modified command:

sshfs -p 22 client@server1.net:/home/client/exchange/ /home/user/remote/server1/ -o follow_symlinks

In the next step, we will make the connection and mounting more comfortable, even if you are handling with more than one server.

Using hostnames

Now that you know how (and that) the system works, we will make it easier. Of course it is quite annoying to type in the whole server-address and port each time. Instead of sshfs -p 22 client@server1.net[…], you can simply type sshfs server1. How? Just open the SSH configuration file /home/user/.ssh/config with you desired text editor and add:

Host server1
  HostName server1.net
  Port 22
  User client

Save it and try to use this shortcut. It also works for normal SSH connection like ‚ssh server1‚. For the Host variable, you could use any name you can remember easily, for instance privateserver.

Using Public and Private Keys

Pretty smooth, isn’t it? Well, it gets even better! You have to admit that typing a password each time you connect is quite harrassing. This gets even worse if you are used to connect to many servers. On the one hand, you could use password managing tools… or Public/Private key authentication! For those who don’t know much about it, let me say: This sounds terribly complicated, but you don’t have to understand it completely.

For this guide, you only have to know: There are two keys (files). The one is private, you should never give it to anyone! It’s like a key to your safe, if someone achieves it, he can get everything that is secured in this safe. But the other file is public, you can give it to everyone if you want so. Now it gets a bit weird, so I try to make it as simple and abstract as possible.

Let’s say, the public key is a chest that no one except the owner can open. Inside this chest, there is a supersecret word that no one except the owner knows. You put an exact copy of this chest on your server and each time you try to connect, you say „Hey, I’m the legitimate user of this server. Give me my chest, I will open it with my secret key and tell you, what the supersecret word is!“. The server will give you the chest (public key), you open it with your private key and tell the server the supersecret word. If you were right, the server lets you in.

Note: This example is so ridiculously abstract that I had to laugh while writing it down. Every security expert, IT guy and cryptography scientist would knock me down for this but I hope it made you understand the principle of this very smart method. And if you ask yourself now „Why does the server know the supersecret word? Isn’t this insecure?“ or „Isn’t is insecure to send such a sensitive code word over the internet?“: You’re absolutely right! But be assured, that the public-key cryptography uses some awesome tricks to avoid security leaks like these and others. If you want to, read about it!

It is quite easy to make this system happen. Again we need a terminal to generate the two keys:

cd ~/.ssh/
ssh-keygen -t dsa

This neat script asks a.) in which file you want to save the new keys. The standard is set to /home/user/.ssh/id_dsa and I recommend this. Most programs automatically search for keys in this destination. In step b.) it asks you for a password. This is quite important because if someone achieves your private key, he still needs a password to use it. After this short procedure, you have two new files in /home/user/.ssh – id_dsa and id_dsa.pub. As you can imagine, id_dsa.pub is your public key, the other is the secret one.

Now we have to put the public key (chest) on the server we want to connect to. This could be done by a simple command:

ssh-copy-id -i /home/user/.ssh/id_dsa.pub client@server1.net

By this, you automatically connect as a legitimate user to your server (with the password used in step II) and put the public key in the /home/client/.ssh/authorized_keys. This file simply collects all public keys (chests) of users that are allowed to connect to the server. If a stranger tries to connect to your server but there is no chest his secret key belongs to, he of course cannot open the connection to your server.

Now disconnect from your server and try to connect via ssh server1. Your device should automatically search for your private key and open the connection with it. As you notice, you are still asked for a password. This is because you (hopefully) put a password on your private key (remember?). But after you typed in the password once, it should be saved for duration of your local session in a local keyring.

If this is not the case or you want to make your configuration even better, add the following lines on the bottom of your /home/user/.bashrc (or if you’re not using bash, the respective rc file of your shell):

alias ssh='ssh-add -l > /dev/null || ssh-add -t 7200; ssh'

By this, you say to your shell: „Everytime I type the command ’ssh‘, you should instead (alias) 1.) check if I already added my key to the local keyring. If not so (||), 2.) add my key to the keyring, but only keep it there for 7200 seconds (you can also keep this away or increase it). Only if you made this sure, use the command ssh to connect to my server“. Every command line program that uses ssh to connect to a server (and there are some, e.g. git, sshfs…) now uses this procedure – no matter if you close the terminal or lock the screen.

Of course, this also works with sshfs to mount your remote storages. If you remember our first line to mount the server, we have a much shorter line now without any password request:

sshfs server1: /home/user/remote/server1/ -o follow_symlinks

And these steps were quite important for the next section where we will write a shell script to make it much more easier – and even graphical!

Using a shell script

Our setting is very smooth now, but it could still be improved. If you want to connect to many servers and don’t want to use your shell every time or don’t want to remember the HOSTs you used in your .ssh/config, you’re free to modify and use this shell script:

#!/bin/bash

### VARIABLES TO BE CHANGED ###
# Preconfigured HOSTs in ~/.ssh/config that should be used
PRESSH[0]=server1
PRESSH[1]=server2
PRESSH[2]=server3

# Local directory where the remote storages should be mounted to
LOCALMOUNTDIR=/home/user/remote

### THE SCRIPT BEGINS HERE ###

# Add SSH key to local keyring if not already happened
function sshadd {
	ssh-add -l > /dev/null || ssh-add
}

# Choose preconfigured HOST to mount
function mount {
	if ! SSH=$(zenity --list \
		--height=300 \
		--text="Please choose. Cancel to unmount drives." \
		--title="Choose SSH server" \
		--column "Preconfigured SSH servers" \
		${PRESSH[*]}); then
		unmountquestion		# If you press cancel, it should ask you to unmount all drives
	fi

	# If you double click on an entry, it gives 'server1|server1' as result instead of 'server1'
	# This command cuts of everything after |
	SSH=$(echo $SSH | awk -F\| '{ print $1 }')

	# Make a local directory if not available
	if [ ! -e "$LOCALMOUNTDIR"/"$SSH" ]; then
		mkdir -p "$LOCALMOUNTDIR"/"$SSH"
	fi

	# Command to mount actually
	sshfs "$SSH": "$LOCALMOUNTDIR"/"$SSH"/ -o follow_symlinks &

	quitquestion	# one more ssh server or quit?

}

# Ask if all preconfigured SSHFS drives should be unmounted
function unmountquestion {
	zenity --question --text="Unmount all preconfigured\nSSHFS drives now?"
	if [ "$?" = "0" ]; then
		unmount		# unmount function
	else
		exit 0
	fi
}

# Procedure to unmount all preconfigured SSHFS drives and exit program afterwards
function unmount {
	for ((i = 0; i < ${#PRESSH[*]}; i++))
	do
		fusermount -u "$LOCALMOUNTDIR"/"${PRESSH[$i]}"
		echo ""${PRESSH[$i]}" unmounted."
	done
	exit 0
}

# Should another SSHFS storage be mounted?
function quitquestion {
	zenity --question \
	--text="Mount another SSHFS storage?"
	if [ "$?" = "1" ]; then
		exit 0
	fi
}

sshadd		# sshadd function

# Loop for endless mounts until stopped by unmount or unmountquestion
while :
do
	mount	# mount function
done

Save this script to some place (e.g. /home/user/sftp-mount.sh) and make it executable (chmod +x /home/user/sftp-mount.sh). For example, you are now ready put a shortcut in your panel or on your desktop to make it easily accessible. Please note that zenity, sshfs and ssh-askpass should be installed.

Please test the procedures written above on your servers and (if they have SSH access) webspaces. On my 4 webspaces and my vServer it works perfectly with my Debian Sid system. Please contact me or write in the comments if you have any problems or if some steps could be improved – nobody’s perfect :)

Appendix

I know following hosters that provide webspace with SSH access. This list is very short so please add more by writing in the comments!

uberspace.de (All plans, starting from 1,00€/mon, focussed on german residents) <– great hoster by the way!!
OVH.com (>= Business Hosting, 5,94€/mon)
HostGator.com (All plans, starting from 3,96$/mon)
All-Inkl.com (>= Premium, 9,95€/mon)
Hetzner.de (>= Level19, 19,90€/mon)