New release of uftpd, this time with TFTP blocksize negotiation, RFC 2348. Making it a lot faster to transfer files over TFTP.
This is a very short blog post, mostly intended as a reminder to
myself. Assumes the
src.txz was installed previously. Here goes:
cd /usr/src cd sys/amd64/conf cat GENERIC | sed 's/GENERIC$/MULTICAST/' > MULTICAST echo 'options MROUTING # Multicast routing' >> MULTICAST cd - make kernel KERNCONF=MULTICAST reboot
That’s it. Remember to make sure your Qemu VM has enough RAM or it will probably page fault on you. I use 1,0 GB RAM.
Also, thanks to a friend of mine trying out uftpd recently I discovered that libuev has been missing from the tarball since the release of the TFTP support. Fixed.
So them pesky details of `/etc/inetd.conf` really are important?
This is a small bugfix release of uftpd. Version 1.4
is basically just to change
wait for the TFTP service in
/etc/inetd.conf, but there’s also a minor man page update.
Today sees the release of v1.3 of the awesome little uftpd. The main news is the new TFTP support! Just like before you don’t need any configuration file, just build and install — or build a .deb file and install.
This release completes the main purpose of uftpd for me, I can now use it as my daily driver and fully replace vsftpd and tftpd-hpa, which to me are the next best.
What’s left then, you ask? Well, TFTP upload support, TFTP segment size negotiation and possibly multiple user support in FTP. As always, patches are most welcome. See the uftpd homepage and my GitHub project for details.
OK, so you’ve just been handed the task to integrate a big piece of corporate software and it’s nowhere near as done and ready as project management thinks. Of course you’ve already started chugging away at it, fixing bugs, refactoring code and wrapping it in neat containers to keep the changeset against the base SW small — you already know you’ll get another drop of the same stinking pieace of code in another six months, so you keep the changes small and track them in GIT with neatly formatted commit messages.
About ten commits in it dawns on you that you have several commits
that would need to be squashed and some commit messages that needs to
be edited … you start typing in
git rebase -i origin/... wait, you
haven’t pushed anything yet. So how do you rebase something that’s
not been pushed yet?
git rebase --interactive --root master
Tip courtesy of my friend and collegue wkz
It’s actually a rather depressing development. They claim it’s due to the low traffic and decline in updates, but it’s evident that’s not the whole truth. The owners recommend their other site, SourceForge, but anyone having been in the loop for the last decade or two knows that SourceForge has been in a slow decline for a long time, more so than free(code) in my opinion. Also, SourceForge only lists its own projects, and only the most active or “top” projects.
I never used free(code) to find the “top” projects or the most active ones. That’s completely useless to me. I went there to dig for small unknown projects, small gems that are usually unlisted on GitHub or SourceForge. I went there to publicize my own small creations, learn about other similar projects and get a quick feedback on recent changes of new releases to projects I was interested in.
There exist no real replacement to free(code), except perhaps for Open Hub, previously known as Ohloh. The Free Software Directory could perhaps have become something over time, but unfortunately feels like yet another Cathedral Style project from the FSF. Don’t get me wrong, I love the FSF and almost everything they do, but they often get lost in their old tradition of big closed off idealistic projects. Eric S. Raymond has a proposal for replacing free(code) and he is that sort of pragmatic person that could get something off the ground. In any case it’ll be interesting, I’m sure.
Some people say all the action is on GitHub these days, but that’s just like an echo of the glory days of CVS, Subversion and the start of the new millenia when we should all use SourceForge. Been there, done that, and yes I do use GitHub, but again it doesn’t list anything but GitHub projects …
Other people say that to promote your small projects you need to become active in a Linux distro, or write about them in magazines or on Hacker News … well, I’d like very much to become a Debian developer one day, but the process to become one seems so increadibly daunting! Also, I’m not a writer, nor am I a native English speaker, I’m just a programmer and I really miss free(code)!
I don’t expect this blog to have any readers at all, so using it as the sole platform for announcing new releases is rather pointless. So I’ve started playing around with Open Hub for my own most relevant projects. It has some nice stats and other useful features that I can use. Hopefully it can serve as a replacement for my most basic needs.
The last couple of weeks have both seen the birth of the fabulous uftpd and a reignited inadyn project! Yesterday v1.2 of uftpd was released and today Inadyn saw the first working HTTPS support being released as v1.99.8! This is likely the last release of Inadyn before the big 2.0, which will introduce the new .conf file format based on libConfuse. A .conf file feasibility study was presented earlier …
The uftpd project is completely based on user input, currently mostly mine. I will add features and bug fixes when I need them, unless I get more input. So I welcome anyone to clone it on GitHub and hack away. As usual, I will accept any sane patches that adhere to the coding style and is well written. The same goes for Inadyn, only with the added request that the changes are thoroughly tested first, since I cannot maintain multiple accounts on various DDNS providers myself.
Patches to support flavors of UNIX other than GNU/Linux, including GNU/Hurd, or even other operating systems are also welcome, as long as it’s not Windows. I will not maintain any Windows support since I don’t use it myself. If you want Windows support you will have to take a very active co-maintainer role in the respective project.
Looking for a Dynamic DNS, DDNS, client? Well you’re in luck, the FLOSS market space is flooded with dedicated clients and various wget scripts. So why bother with an old C implementation? Well, this is admittedly one of the old timers in the game and is likely packaged for your GNU/Linux distribution of choice already. It’s tried and tested with many DDNS service providers and even comes bundled in a few embedded router distributions as well.
Today I’ve released Inadyn v1.99.7 as an XZ compressed tarball. The release announcement should be up on free(code) now. It’s a small incremental release containing mainly code cleanup and a few new features that you likely won’t notice: support for multiple cache files and DDNS providers as separate plugins, for easy addition of new ones as well as maintenance of existing. This further separates the internal logic from the provider specific parts and also helps reduce clutter to ease maintenance.
This is a small incremental release building up to the long awaited v2.0, which will include the long-awaited HTTPS support and also a new .conf file format. The latter is not really welcomed with open arms by users, but is a necessary step since the current parser is heavily affected by bit rot and must be put down. I will attempt to make the transition as easy as possible, but you will need to change you .conf files.
Maybe a preview of the HTTPS support will make it into a release that still has the old .conf file format, but just maybe.
So, I finally got fed up with all other FTP servers and wrote my own. Why would someone in their right mind do something like this 2014?
As a developer the answer to most such questions is usually; to scratch an itch. For a very long time I’ve looked for a really simple FTP server that just works, out of the box!
My alternatives on GNU/Linux distributions have been: several variants of the original MIT/Athena ftpd, ProFTPD, Pure-FTPd, and vstfptd. Most of them are too damn difficult to configure, have ugly configuration files or are plainly just too confusing. With one exception, vsftpd. I really like vsftpd! It’s got a simple and well documented configuration file (inline as comments) and always worked almost painlessly for me.
However, over the past couple of Ubuntu LTS installations it’s been starting to act up on me. Not allowing me to have a group-writable root directory, and not even an ability to disable that security feature.
It’s simple really. I’m a developer. I have colleagues. We share
servers at work. We bootstrap and upgrade our embedded devices using
TFTP/FTP. We have one directory, usually
/srv/ftp, which is group
writable and all developers are members of that group. Anyone can
upload a file there and the file servers … would you know … are
supposed to serve that file, as TFTP or anonymous FTP.
Maybe I’m a fringe user? Maybe secured local area networks, or laptop to embedded device crossed-cables networks, are no longer the “fad”? Maybe a sane built-in default is no longer cool or hipster enough?
I don’t know anymore, and this time I was so fed up chasing around for answers to “How to setup your ‘favorite’ FTP Server”, that I just sat down and fixed it once and for all. I figured I’d otherwise be doing this waltz over and over again, just like I already have, for the next 10 years …
I trawled the net once more for good candidates, this time for adoption and holy cow sacrifices. I wanted a very simple base to start from, which I could cut up into pieces, iteratively refactor and improve upon until I was happy. That took a while.
I’m a big fan of both the Free Software and the Open Source cultures. (They are slightly different you know.) I routinely work on software with GNU GPL, MIT/X11, Apache, and ISC licenses, but for most of my own creations I usually lean towards the very permissive ISC license. Maybe because most of my hobby work these days are quick and dirty hacks I don’t really care enough about. It’s a question of both taste and appropriateness — like software patents, I don’t like them either, but for anything which I have a great investment in, or has a great threshold of originality, I’d use a more restrictive license to make sure the software is kept in the open.
Anyway, I read much code, discarded several projects that were too big, too unreadable code or simply didn’t feel right. I tested so many small “FTP” servers that turned out to be unusable homegrown variants or school projects. There’s a lot of code out there … I finally settled on FtpServer by Xu Wang as a base for my little project. I suspect it too is a school project, but this one actually worked, right off the bat!
I got so excited that I immediately started improving it, cleaning up the source code, reindenting it (KNF) and fixing small bugs here and there. It was a perfect fit! This is where I made my big mistake, which I hope will not eventually kill this project in the end — the FtpServer project did not have a license … so I filed a bug to the GitHub issue tracker, added the ISC license to my fork and continued hacking away. The changes I’ve made are so substantial that there isn’t much left of the original code, so uftpd should be safe. Yes, I named it uftpd, the micro ftp server — the no nonsense file transfer protocol daemon.
The whole hack took about three days and I’ve learned a lot during this time! It was fun, inspiring and gave me a lot of creative energy that I can use in other projects: at work as well as at home :)
See the uftpd project home for download links.