http://hannibal.solstice.nl/hannibalwiki/ 2010-06-03T09:45:35+02:00 http://hannibal.solstice.nl/hannibalwiki/ http://hannibal.solstice.nl/hannibalwiki/lib/images/favicon.ico text/html 2010-06-01T16:57:46+02:00 olivier http://hannibal.solstice.nl/hannibalwiki/doku.php?id=hannibal:postfix&rev=1275404266&do=diff Mail transfer agent Wietse Venema's Postfix hasn't caused us a single bug or security issue in several years of usage, pretty impressive right!? In order to fight spam the deployment of greylisting software (we chose postgrey) appeared very adequate. Tnx. to Arjen Baart for mentioning this! text/html 2010-03-28T16:37:11+02:00 luc http://hannibal.solstice.nl/hannibalwiki/doku.php?id=hannibal:cyrus&rev=1269787031&do=diff Mailstore Hannibal promotes the use of Cyrus-imapd as the scalable solution for building mailstores. It supports POP, IMAP, SSL/TLS, serverside mailfiltering and the software appeared very robust during years of usage. We assume you build the mailstore apart from the frontend SMTP-server(s) on a separate server or virtual server. LMTP over TCP will be used to deliver mail to the backend mailstore. User access to mailboxes will be authenticated via SASL to your LDAP directory server. text/html 2010-03-08T12:27:56+02:00 luc http://hannibal.solstice.nl/hannibalwiki/doku.php?id=hannibal:ldap-auth&rev=1268047676&do=diff PAM and NSSwitch are necessary for LDAP-authentication/authorization of users on our GNU/Linux servers (and possibly also our GNU/Linux workstations). Furthermore you could configure several applications such as the Cyrus IMAPd, Openvpn, ProFTPd, Jabberd2 etc. to use PAM/NSSwitch for user authentication/authorization against LDAP. In this case you won't need to add special LDAP-patches to your services. Just configure them to use PAM/NSSwitch. text/html 2009-07-23T13:17:20+02:00 luc http://hannibal.solstice.nl/hannibalwiki/doku.php?id=xen:installation_of_dom0&rev=1248347840&do=diff Debian Etch (current) Core OS and hypervisor create a bootable system With the availability of 64-bit hardware in mind, we only use the AMD64 port of Debian Etch in order to create Xen enabled servers. There are several reasons for this decision, one of them is to avoid the TLS-issue's with the 32-bit Xen hypervisor on x86 CPU's. text/html 2009-07-20T20:54:18+02:00 luc http://hannibal.solstice.nl/hannibalwiki/doku.php?id=xen:creation_of_a_domu&rev=1248116058&do=diff Debian domU Create stock rootfs Install the debootstrap package on the dom0 if you don't already have that package. Now create a minimal system installation in a subdirectory to bootstrap: apt-get install debootstrap mkdir -p /opt/xen/stock/deb-etch debootstrap --arch amd64 etch /opt/xen/stock/deb-etch ftp://ftp.debian.org/debian (this will use the /etc/apt/sources.list file on the dom0 in order to be able to find the Debian repository) text/html 2009-02-04T19:18:55+02:00 luc http://hannibal.solstice.nl/hannibalwiki/doku.php?id=xen:live-migration_infrastructure&rev=1233771535&do=diff shared storage In order to be able to do live migration of Xen guests from one cluster member to another, some sort of shared storage is required. As the Xen guest won't run on more than one cluster member at a time, a cluster filesystem is not required. That is, as long as you configure Xen to access the Xen guest by a physical device, not a file. Furthermore, if you want to share the Xen guest configuration files, then a cluster filesystem is required as soon as you want to write data to that…