Technical team planning
From Smeuh.org
Things to do before we can migrate.
Contents |
Mandatory
| What | Details | State |
|---|---|---|
| Organisation des BALs | Convert all mailboxes to Maildir format, define Maildir hierarchy tree. | 
|
| Migration des homes | Transfer users' data (home dirs and emails) to the new server. | 
|
| Intégration LDAP, Postfix, Mailman | Mailman doesn't integrate directly with the LDAP directory. Given the present Postfix configuration, it doesn't seems possible to make them work together. Rewrite Postfix configuration. |
|
| Bind setup | Prepare bind configuration, have a template for adding new domains |
|
| Apache setup | Configure apache virtualhosts, php, mod_python, mod_perl, etc. |
|
| MySQL setup | Global configuration, prepare transfer, script backups, naming conventions. |
|
| PostgreSQL setup | Global configuration, prepare transfer, script backups, naming conventions. |
|
| Backups | We should start with backups from day one (especially given the risk any migration brings). Script backups for system and services. |
|
| Network | Write a firewall, IPv6 configuration, etc. |
|
| OVH Guide for Smeuh | There's a lot of things to know about the "OVH way of things" before we can even rent a server, let alone administer it. |
|
| User's applications needs | Inventory user's applications needs: perl/php/python modules, crontabs, etc. |
|
| Prepare Mediawiki | Convert tables and content to UTF-8, migrate to InnoDB, upgrade to Lenny's version (1.12.0), add geshi plugin. |
|
Deferrable tasks
Things that should be done, not necessarily before migrating.
| What | Details | State |
|---|---|---|
| Development | Software development practices that defines management for internal developments : inception, source management, development, test and runtime environments ... |
|
| End users administration interface | Provide means to change passwords, create mail aliases, ... |
|
| System security integrity monitoring | Something like Samhain, AIDES or Tripwire would be good. |
|
| Administrators log system | Something for sysadmin to note and notify their daily interventions (french "cahier d'exploitation"). Twitter like ? |
|
| DSPAM test | With PostgreSQL + Postfix + LDAP (ben: not sure this is desirable as such). |
|
Things needing a decision from us
Disks/Partition layout
- We will have two 500 GB SATA drivers. Should we use them aggregated in a raid1 setup or split them (ie. to keep more backups) ?
- In both cases (raid1, or one drive for backups) we will have 500 GB for useful data.
Layout proposals
- Proposal1 (ben)
The two largest partition (/var and /home) are left contiguous at the end of the disk, so we can resize them later if needed. 4 last partitions (/var/, /var/mail/, /var/www/, /home/backups/) over LVM (or no LVM?).
Start with a RAID1 setup and use /home/backups/ as storage area, then adjust later if needed (ie. by removing the second drive from the raid array, or by asking users to clean up their folders, or by renting an external 10 euros/months 500 GB usb drive from ovh, or tightening the excludelists, ...).
| Mountpoint | Size (GB) | Comment |
|---|---|---|
| / | 15 | Leave enough room for future debian upgrades (anticipating debian to become bloated :). |
| swap | 4 | We have 2 GB ram, and idling services that the kernel would page out with default swapiness sysctl. |
| /tmp | 4 | Generous |
| /var | 10 | Logs should be daily archived anyway. This will also contain the databases (LDAP, MySQL and PostgreSQL). |
| /var/mail | 40 | Maildirs |
| /var/www | 200 | Websites |
| /home | ~240 | For now the largest partition (in disk usage) at reynerie. This should also contain /home/backups/ |
Various
- What about changing OpenSSH default port (to, say, 2222) ? That's not rocket security, but enough to avoid many blind brute force attacks.
- User's shell: what about providing a "scponly" shell for users with website but without rights to execute interactive shell commands?
- Is it tolerable to have an "insecure" web setup (in which one website app can read config/files from an other website)? This can be avoided for PHP and CGIs using suPHP and suEXEC, but won't cover mod_python, mod_perl etc cases, so is it worth it ?
- Secondary NS: will we use OVH's one ?
- User's home directory: note that mails are in /var/mail, web things in /var/www/vhosts/, so homes would mostly be used by users with an interactive shell account. The pam module "pam_mkhomedir.so" can create users homes dynamically as needed.
