_cbdev

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]

[1] https://github.com/cbdevnet/fugit [2] https://git.zx2c4.com/cgit/

I’ve uploaded a few videos of the tool in operation to Twitter:

MIDI->evdev https://twitter.com/twitter/statuses/965384962848456704

evdev->ArtNet https://twitter.com/twitter/statuses/965337284982837248

MIDI<>OSC https://twitter.com/twitter/statuses/882368440811606020

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:

https://github.com/cbdevnet/fugit

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).

Keep up the great work!

By '1 IPv6' you mean at least a /64 (for the lighter plans), right? Otherwise, this seems very shortsighted...

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.

Sadly, it does not support IPv6 :(

Other than that, this was unexpected :D

Because I'm writing my own ;)

https://github.com/cmail-mta/cmail if you're interested.

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 ;)

FWIW I enjoyed the challenge of hacking up my own version of this. It's admittedly not battle-tested, but hey ;)

https://github.com/cbdevnet/libgit2-backends/blob/master/pos...

I decided to do it just for the fun of it.

https://github.com/cbdevnet/libgit2-backends/blob/master/pos...

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.

Well one reason being I really like SQLite.

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.

If you're interested, check out https://github.com/cmail-mta / http://cmail.rocks/

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.

Definitely a great and very instructive read, and one of the few to include IPv6 and the correct usage of getaddrinfo.

It's the guide I recommend to everyone who wants to learn about network programming in C. I actually purchased the (slightly expensive) printed version and never regretted it :)

http://www.lulu.com/shop/brian-hall/beejs-guide-to-network-p...

That already happened.

See http://www.iana.org/domains/root/db

I am amazed no one suggested a simple GPG operation.

Generate a keypair on an airgapped machine, keep the private part on a secure external medium (eg. CF Card in a bank safe).

Have the public key on your normal machine, write your journal in normal text files (use a ramfs if you worry about it being restored by forensics) and encrypt against the public journal key. Decryption is only possible with the private part, the public part can even be, well, public. :)

I especially like the absurdity presented in this diagram:

http://sshkeybox.com/img/keybox_dia.jpg

Not only does it create a single point of failure in the Administration, but the third case illustrates that this is some kind of feature, advertising blocking normal SSH traffic to the server network, instead replacing it with HTTPS traffic.

Please don't do this. Just accept SSH and learn to deal with it. If you can't, maybe systems administration is not for you and you should pay someone to do it.

> Keyless in the first password manager to provide complete hacking protection.

Uh-Huh. Pretty strong words there. Lets for a moment ignore the fact that this claim is ridiculous and companies or individuals making it should never be trusted, I can't find anything on your webpage that goes beyond marketing copy and "it's Magic!" rhetoric.

Seriously, not one technical statement?

To stand any chance in that market I'd strongly advise you to include more detailed descriptions of how your "magic" works. And you can't use full-page photographs in it.

>companies need to replace their switches.

Actually, most Switches are just fine and don't need replacing. IPv6 is a Layer 3 Protocol, most "Normal" Switches operate on Layer 2 (The Ethernet Level, which stays the same and (in the best case) does neither know nor care what goes on in Layers above). These can stay and most wouldn't even need to be reconfigured.

As for Layer 3 Switches (The ones that do some amount of Routing, too), most "brand-name" Models purchased in the last 10 Years should support IPv6.

In my experience, there's an abundance of people just barely able to fire up their favorite IDE and hack something together in some kind of rapid prototyping web 2.7 thingamajig they don't even understand fully, preferrably using the latest JS(-based) framework and a (seemingly) random combination of currently hip "stack" technologies and packing all this on about 5 to 10 'cloud' instances without any knowledge of anything beyond the web.

So, while I agree with your 'Or at least, it's supposed to :)', there's an awful lot of people whose claim to 'Hackerdom' is going to some kind of 'Hacker School' or '-Weekend'.

Exactly what I thought. The technical "difficulty" of joining an IRC Channel through the ancient incantations of actually using a text-based interface instead of some fancy Webapp is enough of a deterrent to serve as basic divider between the people you want to have in a channel and the rest.

The barrier of entry to this thing seems to be the goodwill of "someone".

First thought on the Website: Don't do that. Don't force me to go through lengthy animations, just show me your actual content and let me use it like I use the rest of the web.

Second: The 'Learn more' presentation actually says nothing, nevermind that the start page is equally uninformative. Not a single word about techniques used or what makes this service supposedly 'safe' or why I should trust it with my data.

I am highly suspicious of anything claiming to be "safe" or "secure", expecially when it is this dodgy around details. I'd not advise anyone to actually use this for anything sensitive.

EDIT: Just noticed the tiny light-grey 'About' link at the bottom, which gives a little more info. Still, I absolutely dislike the site design.

There is also the matter of directly stuffing the sockaddr_in with calls like inet_addr(), which has long been considered inferior to alternatives using getaddressinfo().

This also has the side effect of this implementation not supporting IPv6, among others.

So please, don't use this as anything other than an example how not to do sockets.

If you want to learn how to do it right, I can recommend the excellent "Guide to Network Programming Using Internet Sockets" by Brian "Beej Jorgensen" Hall (You should definitely buy the printed version, just to support him :)).