At Sun, 25 Jul 2010 19:17:05 +0300, Александър Шопов wrote: > Със zver-а има монотонно увеличаващ се брой проблеми много малък > брой администратори с физически достъп от него
Това е реален проблем. Трябва да има поне един надежден човек с локален достъп. За „отдалеченото“ администриране се бяхме разбрали навремето -- мога да помагам редовно, макар и да съм далеч от квалификацията на Васил. Засега може би е най-належащо да се мигрира към поддържано издание на Дебиан. Ако машината има хардуерни проблеми, бихме могли да организираме бърза кампанийка за набиране на средства (диск или там каквото е необходимо). > В момента имаме предложение от Васил Колев миграцията да бъде към > машината marla. Страничен въпрос: Ще се запази ли домейна? Ако не, поне ще има ли период на миграция на личните данни? Питам, защото zver в момента е единственот място, където мога да „хоствам“ мои неща (разбира се, ограничавам се само в рамките на свободния софтуер). Имам хранилища там, които са обявени в официални ресурси, напр. $ apt-cache showsrc kazehakase | grep Vcs Vcs-Arch: http://fsa-bg.org/~yavorescu/{archives}/[email protected]/kazehakase--debian--1.0 > 1. Ползваме Trac. [...] Моите промени са за елементарна борба със > спама. Има стандартен пакет в Дебиан за това (не знам доколко е ефективен в сравнение с твоя хак). > Коментирайте, плиз. Мислил ли си за хостване на някоя от свободните платформи като Савана? Има съществени недостатъци, например: * Няма уики (засега). Като заместител може да се ползва система като ikiwiki (вж. http://gnu.org/s/hurd, изцяло поддържан по този начин) или много опростен HTML. Или пък някакъв уики-подобен формат като ReST с автоматично (чрез cron) конвертитране. * Няма локален достъп, и оттам -- финтифлюшки, магарийки, подобренийца и т.н. Евентуално мога да изврънкам акаунт(и) и пространство (вкл. поддомейн) на chapters.gnu.org (това е машината, която хоства gnupdf.org, es.gnu.org, it.gnu.org, gnuzilla.org и някои други ресурси). Хубавото при този вариант е, че не се администрира от GNU/FSF sysadmins, които са на работно време и често са мноооооо мудни. * Няма Trac. Това е сигурно най-големият недостатък. Миграцията на базата от данни с регистрирани грешки (вкл. разрешените) не ми се струва лека задача. Иначе от гледна точка на потребителя тракерите на Savannah са по-лесни за ползване от Trac (имат си други кусури, разбира се). От друга страна, сещам се поне за няколко големи плюса: * Не се занимаваш с нищо. Savannah има процедури за възстановяване на хранилища и база от данни на тракерите при сривове, която работи добре. Не се кахъриш за архиви и тем подобни неща. * Много поддържани VCS, като може да има множество модули (напр. gnome.git, kde.git, etc.) за проект. Може и един проект да има няколко активирани VCS -- напр. GNOME в SVN, GNUstep в Arch, Mozilla в Mercurial и т.н. * Пощенски списъци -- има система за „човешка“ модерация (listhelper [1]), която работи удивително добре. Администрирам 6-7 списъка на lists.gnu.org и не се сещам да съм правил нещо специално, нито пък да се е промъквал спамец. В момента в dict@ и dict-notifications@ няма спам, но настройките на списъците са изключително враждебни -- всяко писмо от неабониран подател се отхвърля автоматично. (Предполагам затова не получаваме уведомления от translationproject.org, Дебиан и т.н.) Със сигурност може да мигрираме целия архив (барабар със стария, съхраняван някъде от Оги). Просто подхвърлям идея за размисъл. Може би не е съвсем удачна, но в дългосрочен план вярвам, че ще се почувства облекчение. [1] http://savannah.gnu.org/maintenance/ListHelperAntiSpam _______________________________________________ Dict mailing list [email protected] http://zver.fsa-bg.org/cgi-bin/mailman/listinfo/dict
