Archive
You are currently browsing the archives for the RavenCore category.
By cormander
I’ve been hemming and hawing on whether or not to change the license for my RavenCore software from GPLv2 to something else. There is a lot to consider, and of all the licenses I have looked at, none of them do exactly what I want.
The disadvantage of the GPL license is that it limits freedom in the form of disallowing other developers from using GPL code in their software, if the software they write is not released under the GPL as well. This is a problem for users as not everyone wishes to release their own code under the GPL.
The disadvantage of the BSD style licenses is that they place no restrictions whatsoever on reproducing modified source code when changes to the software are published. This is a problem for me as it is my goal to keep the RavenCore project open in the sense that changes made to RavenCore that are published by other people remain open to everyone else.
The LGPL license would be perfect for me, except that it is too fuzzy to use. The LGPL talks about linking and machine code, and since RavenCore is Perl code, and the idea of linking in the world of Perl is less obvious than it is in a compiler language such as C, questions are raised. Things become even less clear when your program is not even written in the same language as RavenCore, yet your program couples with it via the API. Is your program a derivative work or not? That’s a scary question, legally speaking.
Today I almost just said screw it and put the BSD license in there; but then realized the license is short enough, maybe I could modify the 2nd clause to instead of having binary format reproduce the copyright notice, rewrite that clause to require binary format be accompanied by source form. But at that point it wouldn’t be the BSD license anymore, so lets call it the RSD license (RavenCore Software Distribution, rather than Berkeley).
I looked up RSD to see if it was already an acronym for anything, and here we go:
Reflex Sympathetic Dystrophy (RSD) – A pain syndrome caused by an abnormal sympathetic nervous reflex.
You know what? All this licensing crap gives me RSD; a nervous reflex in my abdomen, and it’s very painful.
Perhaps the irony of this is too good to pass up, and I should actually make an RSD license to license RavenCore under.
By cormander
The past week I’ve been talking about Hudson, and not just here. Quite frankly I think some of my buddies are sick of me talking about it. For this (and other) reasons, I exposed the build system at this URL:
http://build.cormander.com/
I granted anonymous view access to most of it. I currently have ravencore in there, and my grsecurity stack setup in there and building successfully. Pretty soon I’ll be putting rootsh and other projects I manage in there, as well as things like python26 for CentOS, Xen 3.4 for CentOS, and any other thing that comes to mind that I have built and made use of.
And as far as this saving my world goes, it’s because it reduces the amount of effort I have to put into this stuff, which means I can do more of it.
By cormander
At work, we use Hudson (https://hudson.dev.java.net/) to manage all the various projects for the software development teams. It’s primarily a tool for java, but can do general purpose builds as well.
Well, I decided to take a crack at it myself, and I really like it. I pushed a few commits up to the ravencore git repo to make builds work in hudson today. Now I just will have to configure it to build a snapshot each time it sees a new commit, and export those snapshots via the web.
It’ll at least give the illusion that ravencore is an active project, right?
Seriously, though, I feel like I’m slowly moving toward that developer “sweet spot”. I’ve got full revision history with a tool I really like (git), build scripts to automate things, and now a build management system.
By cormander
Here is my proposed architecture for Xen being incorporated into RavenCore:
* Everything is based on a resource, eg; CPU, memory, disk, IP addresses, etc
* Resources are “detected” when you add a dom0 (xen host) to the cluster
* The total number of resources in the cluster are put into the “Administrative Resource Pool”
* The admin user create clients, and can assign them resources. The total number of client resources cannot exceed the amount in the admin pool (for obvious reasons)
* The clients can then use those resources to allocate as many virtual machines as they like – one big virtual machine using it all, or many small ones using a small portion each.
* A virtual machine, if desired, can be defined as a “shared host” and that client then has administrative rights to the provisioning of domains, email, etc on that virtual host. Basically, they get RavenCore as it is today on that VM
* If you add a server to the cluster that is not a dom0, it can still be defined as a “shared host” and either assigned to a client (who will become the admin of it) or just create clients on it directly.
What I want to stay away from in this design, for now, is hardware dependency. In particular, dependency on storage. To start with anyway, I’m not going to build in logic in the interface for things like a SAN. If you have one – great – you will be able to use it, but disk configuration is manual. Basically, when you install the control panel, you tell it what disk(s) you’d like to put into the admin pool. You have to manually create them (either fs files with dd, or a physical disk itself, or LVM logical volumes) and then point to them from the interface.
By cormander
Look at the wiki for these updates. To summarize, the 0.7.x series expands portability, security, and lessens administrative and code overhead. The version 1.0.x series will add multi-server control using the SRCE project, located at http://srce.echoreply.us/
On the SRCE note, I started using it about a week ago. I really love it, and am very confident that I’ll be able to include it as an add-on to RavenCore for multi-server support not long down the road.
Anyway, in a battery of tests of SRCE I noticed something fishy and brought it to the attention to the developer, providing him with a patch for the issue. Less then 12 hours later he posted it as a security patch on the mailinglist which contains the patch I sent him, for srce-exec.c, along with a configuration change. Yay me.
By cormander
I’m starting to get more things into my public packages repo:
http://www.ravencore.com/packages/
The latest of them include SRCE, amavisd-new, dovecot, and sqlite. For now only the source RPMs are being posted because I don’t have the space or bandwidth on this tiny VM to do much else. Once I get a full machine colocated somewhere, I’ll be throwing them all into a YUM repository.
My goal is to provide stable versions of the latest software which matter in the realm of RavenCore. You can stick with an enterprise distro and still have all the nifty features of some select packages.
My latest accomplishment with the new mail configuration is getting postfix to work with amavisd-new-milter, so your mail detected as SPAM actually gets rejects at connect time. Honest mailers will get the rejection right away and know that their mail is being marked as spam, some spammers will not try your email address again (due to logging the 550 rejection) and other spammers will just continue to knock and never get through.
By cormander
OK folks, I’ve revamped my test box’s mail system and everything is working like a charm. Here is the breakdown of how future versions of the 0.7.x series of ravencore will look:
postfix-2.5 built with the sqlite patch and dovecot sasl support
dovecot-1.0 with the sqlite extension
sqlite 3.5.x libraries
All of the above will be published in a yum repo, and will be marked as dependencies for the ravencore package. Just install this .repo file to your /etc/yum.repos.d/ directory and “yum install ravencore”, it’ll grab all of these for you and update them on the system. This will also make what distributions ravencore supports very clear; it will always be the 2 latest CentOS distributions, and the 2 latest Fedora distributions (CentOS 4 & 5, and Fedora 8 & 9)
Depending on how much help I get from other developers, I may or may not publish apt repos for debian packages. That is up in the air for the moment.
RavenCore will no longer use the one-file-per-line format for postfix and dovecot configuration files; it’ll instead use templates: main.cf.in, dovecot.conf.in, etc. You’ll be able to edit those to your liking, just make sure that when you upgrade you don’t miss any important changes in those files that may take place.
Dovecot will reference dovecot-sqlite.conf for user, password, and setup information. That conf file will reference a database in /etc/mail/vmail.sqlite. It’ll also have the dovecot-auth daemon listen for sasl auth inside a private postfix directory.
Postfix will contain a master.cf file that is full of references to other files such as: vmailbox-sqlite.cf, vmaildomain-sqlite.cf, etc. All of those configuration files will also reference the /etc/mail/vmail.sqlite file, each containing a different static query to gather the information needed for that option. SASL auth will be configured to point at the dovecot sasl socket inside of the postfix private directory.
In essence, all mail is controlled by the vmail.sqlite database, everything else is a static flatfile configuration. Since changes to the sqlite database don’t need to be postmapped, postfix won’t ever need to reload automatically. Same goes for dovecot.
To start with, the code will get a transaction lock on the vmail.sqlite database, drop everything, and recreate everything, and commit it all. Further optimizations will be made down the road to better support installations with thousands of email users.
The vmail.sqlite database will look much like what the ravencore database looks like now, as far as mail goes… a domain table and a user table. There may be more tables depending on how far I want to take the features at this point.
By cormander
You may notice something a little different about the blog. If you don’t, they you’re either a new reader, or blind.
I spent some time and got the whole RavenCore website put into wordpress, and moved the directory down to the root of the server. There still may be some quarks to work out, please contact me if you see anything out of wack.
By cormander
Well after spending much of my day on merging version 0.3.3 with much of the latest development code in trunk, I’ve made some very good progress on putting out the first version in the newest “testing” tree of RavenCore.
Here is the feature list I specified earlier:
* use perl Net::Server for the daemon
* enhanced Base64 communication and error handling
* “express install” feature
* port mysql db backend to sqlite, change .shadow file to MD5 hash
* rework how mysql users and databases are managed to survive the back-end’s port to sqlite
3 of those are done. I now have to do the “express install” feature, and rework mysql users.
There are also probably plenty of bugs… hell I’ve fixed a ton already. This kind of thing happens when you try to merge a complete rewrite with legacy code. I even took the liberty of naming one of the files “legacy.pm” because it’s full of version 0.3.3 functions, and I’ve had to modify the hell out of them.
I could package up this code right now and release it under testing, it does actually work for the most part.. but I did say the 27th so I’ll give myself another day to regression test this bad boy.
By cormander
Here are some quick notes I threw together for a road-map over the next few weeks:
0.3.3 released this weekend (by 4/26/2008)
0.7.0 released this weekend (by 4/27/2008)
0.3.3 features:
* apply test patch
* set $rebuild_conf in rehash_named to 1
0.7.0 features:
* use perl Net::Server for the daemon
* enhanced Base64 communication and error handling
* “express install” feature
* port mysql db backend to sqlite, change .shadow file to MD5 hash
* rework how mysql users and databases are managed to survive the back-end’s port to sqlite
As noted above, these should all be done by this weekend. Looking forward, here are my current plans on features moving forward though 0.7.x:
0.7.1
* base engine to “install” things on physical virtual hosts which read a config
make a config to install wordpress
maybe make one for phpbb2
* narrow down the ravencore Makefile and have it call external install scripts
add “clean” option to Makefile
alter install scripts to use .patch files on 3rd party programs instead of crazy sed/awk commands
* httpd.include.tpl template files
one for the whole server
one per-domain
something like this: http://www.ravencore.com/forum/viewtopic.php?t=1016
0.7.2
* upgrade squirrelmail to 1.4.13
* upgrade phpmyadmin to 2.11.5.2
* upgrade awstats to 6.7
* upgrade phpwebftp to 4.0 (5.0 if it’s out by then)
* add email auto-responders, port from DBD::CSV to DBD::SQLite
More info here: http://www.ravencore.com/forum/viewtopic.php?t=1009
* global server aliases, default forward to server admin: abuse, postmaster, root
More info: http://www.ravencore.com/forum/viewtopic.php?t=1028
0.7.3
* alter how amavisd/postfix/clamd/etc configurations are built, use .tpl files instead of the one-file-per-line format that’s used now
* maintain custom version of postfix and dovecot; have postfix use dovecot sasl auth, have dovecot use sqlite auth; configure postfix with sqlite3 patch http://www.treibsand.com/static/files/postfix-2.5.0_sqlite.patch and store vhosts in there
* consider using amavisd-new’s milter with postfix
* consider adding functionality patched here: http://www.ravencore.com/forum/viewtopic.php?p=3661
0.7.4
* use geopt for rehash functions: http://www.ravencore.com/forum/viewtopic.php?t=1029
recreate the “bin” directory and use symlinks to run_cmd to use as aliases
* simple ACL for admin user to lax or restrict what the ravencore admin user can do
* implement the atomic-yum web GUI
0.7.5
* IP-based virtual hosting, SSL-certificate support per-domain
* add support for postgresql databases, add phpPgAdmin
0.7.6
* xen Dom0 host control support via libvirt
