Subscribe to the RSS Feed

 

VIMAGE - Better virtualization in FreeBSD 8

Now that FreeBSD 8 is out, among many changes we can find enhancements in the field of virtualization as well. A newly developed virtualization container called VIMAGE has been implemented to enable virtualization of the FreeBSD network stack.

As you may know previous releases of FreeBSD had support only for jails with IP addresses of the main network stack; meaning once you configured IP/IPv6 addresses on your host system, a subset of those addresses could be associated to each one of your jails. As simple as it sounds, it actually doesn’t let you perform several networking related tasks inside of a jail, and you couldn’t separate your jails from each other with a firewall as there were no real interfaces present in your system.

With VIMAGE you have a jail with full instance of the host’s networking stack, including loopback interface, routing tables, etc. Network interfaces created on the host system can be moved to any VIMAGE jail to enable its connection to the outside world with a new option of ifconfig called “vnet”.

vnet jail
Move the interface to the jail , specified by name or JID. If the jail has a virtual network stack, the interface will disap- pear from the current environment and become visible to the jail.

Note: Option “-vnet” does the opposite.

As you might not have as many network interfaces as jails, you might need some workarounds to tunnel network traffic between two interfaces of your system.

Forget TUN/TAP and VPNs. FreeBSD 8 has a special network device called epair , which lets you create a pair of interconnected ethernet interfaces. If you move one of them to a VIMAGE jail you are basicly done. Feel free to bridge them or use VLANs, they will still work. I don’t know about the overhead of epair, but if all you care about is security, this might be the best choice for you on FreeBSD.

To enable VIMAGE you have to add “option VIMAGE” to your kernel configuration file and recompile/reinstall it.

Posted 2009/11/27 22:06 by jos · Comment [1]


Quota support on Mac OS X

Following this howto, one can enable quota support under OS X.

OS X’s implementation of quota has the <ufs/ufs/quota.h> pointing to <sys/quota.h> and has the same content (structures, macros) as the FreeBSD implementation, except in the struct dqblk dqb_curbytes is present instead dqb_curblocks.

However this is of no practical use, just sharing it for completeness about quota under BSD systems.

Posted 2009/11/27 17:00 by alex · Comment


Sieve, Dovecot LDA, Roundcube howto

Sieve is a standardized e-mail filtering language with many extensions. Its goal is to provide a small flexible framework for various server/client based implementations.
One of the best implementations is the Dovecot Sieve plugin, implemented as a Dovecot LDA (Local Delivery Agent) plugin.
To get global filtering and per user filtering enabled, you have to create an entry into the plugins sections similar to this:

sieve_before=/mailroot/global/global.rules

sieve=/mailroot/%d/%u.sieve

Don’t get confused: there is a sieve_global_* directive as well, but such rules are only executed when the user doesn’t have any rules set in their file.

This way global.rules is always executed before the user’s sieve rules, so you can force SPAM delivery to the Junk folder for every user.
Sieve rules are not run as text-file. At first use the rule files are interpreted and a binary is created with the .svbin extension. Since we have been using per user (UID) delivery we ran into some problems with permissions in the global rule directory. To overcome this you can manually compile the sieve file as for example root, as long as the users will be able to read the .svbin file:

The sievec command accepts two arguments: the script-file argument specifies the script to be compiled and the out-file argument specifies where the (binary) output is to be written. This Sieve implementation reconizes files with a .sieve extension as Sieve scripts and corre- sponding files with a .svbin extension as the associated compiled binary. This means for example that Dovecot’s deliver process will look for a binary file ‘dovecot.svbin’ when it needs to execute ‘dove- cot.sieve’. Such filename is chosen automatically for the binary output when the out-file argument is missing.

To enable the plugin place sieve into mail_plugins:
protocol lda { .. # Support for dynamically loadable plugins. mail_plugins is a space separated # list of plugins to load. mail_plugins = sieve # ... other plugins like quota }

Ok but how should I get the users to write an upload sieve files on their own?
You don’t.

Managesieve is a service for remote management of sieve rules installed on a mail-server. Users logging in with their e-mail accounts are able to install/change/delete rules on their own. Sieve rules are checked and compiled before upload, preventing the user to broke their delivery system.

Managesieve implementation of Dovecot let’s you to get Managesieve listen on a TCP port, so by choosing a port only available locally you can have your webmail application communicating with your sever exclusively.

Lucky for you, there is a Managesieve plugin for Roundcube which allows your users to manage their rules through a Web UI without ever knowing the protocol or the technology behind the scenes.

Initial configuration is easy. In config.inc.php edit the host and port to connect to:
// managesieve server address $sieverules_config['managesieve_host'] = 'localhost';

// managesieve server port $sieverules_config['managesieve_port'] = 13000;

And the result of your hard work:

Posted 2009/11/22 14:57 by jos · Comment


getlogin vs getpwuid

getlogin (2):

The getlogin() routine returns the login name of the user associated with the current session, as previously set by setlogin(). The name is normally associated with a login shell at the time a session is created, and is inherited by all processes descended from the login shell. (This is true even if some of those processes assume another user ID, for example when su(1) is used).

getpwuid (3):

The functions getpwnam() and getpwuid() search the password database for the given login name or user uid, respectively, always returning the first one encountered.

One can get the current username using getpwuid with the following code:

struct passwd *tmp;
tmp = getpwuid(getuid());
printf(“username: %s\n”, tmp->pw_name)

Also note getpwuid_r (3) which is the thread safe version of the above.

Why is it better using getpwuid than getlogin? Imagine you are setting up a chrooted/jailed environment. getpwuid will always give back consistent results, while getlogin will tell different credentials if jexec/su/sudo is used.

Posted 2009/11/17 11:28 by alex · Comment


FreeBSD sources available in Git

FreeBSD is available in Git since September, including most of the releases.

See it here on Gitorious. Together with FreeBSD SVN and FXR this gives a great range to choose from.

Posted 2009/11/16 19:41 by alex · Comment


← Previously Recently →