I prefer to do my project management in in disjunct tools from the actual source control (and I dislike the tech stack of most integrated solutions), so my main repository host is running fugit[1], which simply allows push/pull access on a per-ssh-key basis. Some repositories are then exposed to the Web using cgit[2]
As others have already stated, this article is a great introduction for when you'll be the only one to access the repositories, as anyone able to authenticate for that account will have access to all repos.
There are some tools that restrict access with varying levels of granularity, but if you just want to restrict access on a per-repo-per-sshkey basis, one of my projects is a simple shell script that does just that:
It originally came to be because I've found gitolite too big to maintain for simply sharing some repositories with a few other people. It has since served me well and is used in some business applications, too.
I'd really like to use this if it were just a simple command line tool as advertised. As it is, I can't really figure out what part of the source distribution to run.
The whimsical naming of files and tools IMO drives potential users away more than it helps in engaging people. Mostly it just makes it hard to find out how to use something.
The fact that zookeeper also is the name of another (completely unrelated) software project does not really help, either.
Other than these points, thanks for caring about making the web accessible! All too many websites completely disregard that aspect and ignore users for which these things are deal breakers.
Not to plug my own projects unduly, but I've grown tired of writing configuration files running to hundreds and thousands of lines and kind of snapped and implemented the basic protocols (SMTP & POP3) myself - the project is @ http://cmail.rocks/ (and https://github.com/cmail-mta/cmail).
I've since moved all my mail for the last year (for about 10 domains) via a cmail setup and so far have not had a major hickup. Sure, it may not be as full-featured as other mail servers, but thats not the mission statement ;) One of the main reasons I'll probably never go back (besides pride) is the ease of altering the runtime configuration via our admin tools (eg. adding a new domain to the mail server is one command in the simplest form).
Some of my peers who contributed code or bug reports also run instances and are very happy with the amount of configuration they need to support for cmail vs. the amount of things to do to run for example exim.
Code-wise, it's still C (because that's what I'm most comfortable with), but hopefully it doesn't read as ancient :) I've tried to keep the bulk of it understandable and modular. We extensively use static analysis (clang analyzer and Coverity Scan) as well as fuzzing with afl-fuzz as part of our testing.
IMAP is the only major protocol we do not yet support (though the groundwork is laid in another branch of the main repo), and that's mainly because the specification is a major PITA (at least compared with the relatively sanely specified SMTP and POP3). IMAP also implicitly requires multithreaded handling of connections, which so far cmail has managed to avoid, because in my experience multithreading is a) not necessary in most sane server designs and b) a major source of non-trivial bugs.
Edit: Oh, since you mention build systems - we use a simple makefile, so yeah, no m4 macros ;)
Kind of off-topic, but since I see it (mis-)used here, I kind of dislike how the term 'router' has become synonymous with 'SOHO Wifi Access Point / Modem / Router thingy'...
In most 'professional' settings, all of these things are actually completely different devices with clear purposes, and this script would actually do nothing against a router. It might freak out some APs, but that's about it.
I've been using TC for multiple projects involving Thin Client hardware provisioned in remote locations (such as remote security cameras at a festival and POS nodes/signage displays/twitter walls at conferences) and it really is a great project.
Being able to run a complete distribution off a cheap 128MB CF card is a great thing, especially because the packaging process for TC is really simple - packages are simply squashfs files being mounted to / after booting.
Customization and deployment (editing some files and dd'ing the image to the disks) is also really simple. The package repository is a bit clunky and not as big as you'd get with a major distro, but that should not really be a deterrent (see above).
I've never had those problems with my laptops (though I exclusively use Thinkpads). Multi-monitor works pretty well out-of-the-box with the big desktop managers (Gnome/KDE), and even using xrandr manually is not that hard.
Audio with alsa has also been a painless experience for me, though I heard differently from some people.
Using Debian (which is not well known for always having the most up-to-date releases), I've as of yet never had to compile my own kernel to enable any of these.
I've had mail sent via my own server rejected by gmail because of a missing Message-ID header. The 550 reject message was the standard "Unsolicited Mail detected" text, the same mail was accepted without causing any fuzz once the Message-ID was added.
I copied the prototypes and general structure of the driver from the existing ones (mainly the sqlite driver), implementing the functionality with the appropriate postgres API calls.
As for the implementation by mhodgson, one thing I noticed is that it uses the slightly newer PQexecPrepared API, which only works from protocol version 3.0 and upwards (which was introduced with PostgreSQL 7.4, so not really a problem).
He also seems to use some more calls to the libgit2 API, mainly for copying and creating buffers for SQL statements (which I did with static allocation, at the expense of having hardcoded schema and table names).
All in all, mhodgson's implementation seems more feature-complete (and well-tested) than mine, yet also considerably more complex.
As for submitting it, I'd like to have some confirmation that it works first :) Unfortunately, I'm currently too busy to really set up some tests for it, but once I have the time, I just might ;)
Caveat Emptor: I did not test this since somehow the Debian package of libgit2-dev seems not to include the GIT_* constants. It should probably work, though.
I was aware of dbmail, but did not peruse the source in-depth, in part because it does not in itself implement SMTP.
Archiveopteryx I did not know, but thanks for the tip!
Using their databases as the basis for new tools has the obvious benefits of cross-compatibility, though there's always the drawback of database cruft that accumulates by virtue of differences in implementation or project goals.
SQLite has a pretty great C API making it really easy to programmatically store, modify and retrieve data, which made it my first choice for runtime configuration data.
Adding another storage backend for the mail data would have meant a lot more code paths to support.
SQLite also has a lot of tools surrounding and supporting it (I particularly like SQLiteStudio) which allows querying/modifying/analyzing your mails with a huge number of programs, and using SQL - something I've found really useful!
With a sufficiently sane schema (which I hope we've achieved), transforming from the database format to any other format becomes really easy!
Also, since cmail is not really being developed with the intent to have people access their mail with a shell account (the main reason being that cmail users should not have to map to system users), supporting access formats on the server side is less of a priority - preferred access is via POP (already available) and IMAP (once it's done). The user database feature allows cmail users that ARE system users to control their own database.
An exporter to convert to/from Maildir is a planned feature :)
That's actually exactly what you can already do with cmail ;)
Each user can optionally be assigned a "user database", storing only the mails in her own inbox (which also allows users to have direct control over their own mail database).
If this is not used, mail is stored in the master database.
As you said, most normal deployments should not run into those limits, but its worth keeping them in mind.
> Mail services are usually made far more complicated than they should be, and I understand there are a lot of desired features...
That was my impression of the whole thing, too. I've long had an exim configuration I could decorate my walls with, without understanding what most of it did or if it was secure.
Recently, I got so fed up I began writing my own mail server suite. It's still pretty basic and in development, but it does have some of the features you mention, namely
> SMTP
> POP3
> WebMail (though rudimentary)
> WebAdmin
> Multi-Domain support
In the pipeline, but not yet ready
> IMAP
> Plugins
Some of the goals of the project are to have a mail processing suite with a clear interface between the modules, as well as easy extensibility and configuration.
Me and some people I've talked into testing it already run some instances, and so far it has proved pretty stable.
Caveat: The backend is an SQLite database, so if your use-case is serving a lot of clients, there might be some lock contention.
Adding Shipping Costs to Germany bumps the price to about 22 USD (currently, 21EUR is what the receipt says). Considering the number of pages in this book in relation to its price, it is slightly expensive compared to your average "normal" book.
When comparing to other education text books though I'd not be able to complain. Neither am I, as I still think it was worth it, if just to support the author and to have an addition to the bookshelf.
[1] https://github.com/cbdevnet/fugit [2] https://git.zx2c4.com/cgit/