SOS Sysadmin documentation
This page is done to collect informations about SOS setup and administration, which were previously on SoS
, so that the main page is much clear.
Sos is hosted on nettlau.indymedia.org, root contact is OccAm
We "choose" this server because it fits those reuirements:
- The server does NOT run any mission critical indymedia's services (which couldn't be tracked if the server was down)
- Run both stable and not antique Linux or BSD distro
- Run or can run current version of Perl
- run or can run MySQL >= 4.x
- Run or can run Apache >= 1.3.x
- Run an MTA, preferabily but not necessary with TLS support
- Run or can run backups software
admins will need sudo access, at least to set up the system and the mail gateway and if possible later too. Both server load (no more than 20/30 simultaneous connections on the web server, about 50/100 emails a day) and traffic (about 50MB to 1GB/month) caused by SoS
should be minor, as not being a public site of interest, it will have a pretty mimited user base.
Sos will probably become an important part of Indymedia's IT infrastructure. This it is extremly important to create and apply a reliable backup strategy wich includes ongoing success and failure monitoring.
A backup process have been set up using backupninja
, following the PullBackupsForParanoiacs
ideas. It uses duplicity
handler and backup MySQL
database and sos files. Connections to remote hosts have been secured using the scp restrictions.
- Set up a dev.sos.i.o
- Script the export of otrs public keys to keys.i.o
- Resolve the URI "problem" to have a / for customers and a /admin for admins
- Patch the code to have SOS able to search for unknown customers public keys on keys.i.o
Spam has been an issue on the former install of rt.indymedia.org. A sos will grow, it should become a real problem to deal with. Thus, we should begin to think about how to prevent that. A way to avoid spam would be to install spamassassin and improve spam filters on the mail server. SoS
) has a support for spamassassin headers.
A problem in the previous installation of indymedia's request tracker (ran by RT) was that some request queues' maintainers stopped working in the Indymedia's context, so nobody was left to reply to incoming requests althought they did not stop to fill the queue. They just ended up in the unmaintained queue and the sender didn't even get noticed of that. This is the kind of 'request tracking' we do not have in mind. So we need to make sure this does not happen again.
A way to achieve this would be to create a script, regulary run by cron, that checks when the last queue maintainer action was performed or if unresolved tickets are pilling up in the queue and reports the the sos admins. It might also be usefull to have lists associated with each queues, which would receive monthly/etc remindersof outstanding issues.
- 15 Sep 2005