[Sa] Причините ви за избор на софтуер

[Tocho Tochev]

2012/3/23 Vladimir Vitkov <vvitkov at netsecad.com>:
> Бих искал да чуя на всеки причината/причините за текущия избор.
Като цяло при избора на software в този не-курс съм се водил от няколко неща:
- изискванията на заданията като натоварване на машината
- налично време за подкарване
- да пробвам нещо ново (когато имам времето), впрочем още се вайкам че
заради maniax-а в момента съм на овехтяло ubuntu 10.04 вместо на
bleeding-edge debian testing-а ми

> * защо сте избрали dovecot - май никой не е избрал куриер (или поне мен
> ме мързи да проверявам дали не е)
Никога не бях подкарвал такова нещо и реших да избера него, т.к.
няколко човека казаха че са го ползвали и са доволни.

> * как сте си избрали irc демоните (и защо)
На това можеш да намериш отговор в списъка/логовете от срещите.
Накратко:
- погледнахме няколко сравнения на irc-та
- дисквалифицирахме тези без "commit" в скоро време
- от оставащите които счетохме за ставащи - нашата група (evennet) се
спря на unrealircd т.к. имаше хора които казаха че го ползват и са
доволни, а oddnet избраха ratbox защото maniax-a го ползва
- после, т.к. за сливането трябваше да ползваме еднакъв протокол, с
гласуване решихме че ratbox е по-малката боза

> * защо всички ползват постфикс
Аз по принцип съм на exim и реших този път на пробвам postfix, защото
няколко човека казаха че го предпочитали.

> * защо нагиос + мунин а не монит + какти
munin-а повече ми хареса от cacti (на база на screenshot-ове, видеота,
demo-та и малко четене).
причините са:
- munin изглежда по-добре (чисто субективно)
- не ми трябва през web interface да мога да променям services (даже
го считам за лошо)
- видях че има доста лесна “custom-изация“
- има много live demo-та на munin, докато cacti даже на сайта си не са
пуснали (публично)
за monit не остана време...

> * как си избрахте бекъпа и защо
Ами моето решение е custom tar+gpg(encrypt)+gpg(sign)+(remote:ssh >
backup)+mail notification.
Защо:
- maniax-а каза че трябва да третираме remote машината като по-малко
защитена от server-а и даже remote-a да е компроментиран, backup-a ни
да е защитен (това изключи off-the-shelf backup решенията които
познавам, т.к. използват "plaintext" storage)
- та с оглед на горната точка - gpg за криптиране, така че при
компроментиране на remote да не може да се извлече backup-a, gpg за
подписване - за "checksum" и да знаем че backup-ите на remote-a са
истински
- remote:ssh към server-a - в случай че server-a е компроментиран да
не може да се намаже (много) backup-а (а и server-a трябва да mail-ва)
- email on fail&success - имам познати които са били само с email on
fail и е "много забавно" като се окаже че поради някаква причина
пощата не е стигала до тях
- custom решенията са по-гъвкави (не че не може човек да го симулира и
на off-the-shelf backup)

> * не видях никой да ползва mysql за оторизация и настройка на пощата.
> Така ли е наистина?
Май някой ползваше...
Аз лично не ползвам, т.к. задачата не го предразполагаше (10 aliases,
1 user) и един mysql-a в случая е още едно нещо което трябва да
настройваш, може да се счупи и трябва да следиш... Просто ми се струва
overkill - все едно да използвам mysql за basic authentication на
домашното apache...