a) ano, cesty k binárkám jsem přepsal podle sebe. asi to byla chyba, ale nějak jsem tenkrát nevěřil v to, že se z toho stane oficiální release. a na různý distribuce jsem to neověřoval ... byť mám jak redhat, fedory a teď archy (debiana jsem viděl jenom jednou a nějak mi nesednul). Průšvih je v tom, že na těch starších jsem si je i kompiloval sám, takže je mám úplně všude ... většinou pravda symlinkama. Ale je to v SVN - pokud uznáte za vhodné to vrátit, vraťte to, mě to vadit nebude. Můj názor je, že to není soft pro každého troubu, povinností je stejně konfigurák před nasazením upravit, bez toho to nejde. Když už, tak by binárka měla před spuštěním některé parametry prověřit na správnost.
b) hádky ohledně balíčků jdou mimo mě, zrovna u promethea mi přijdou úplně zbytečný. nějak si neumím představit situaci, že bych ho měl na jedné síti více než jednou ... takže nevidím problém v tom, si ho občas zkompilovat přímo ze zdrojů.
c) co u balíčků úplně nesnáším, když mi přepíšou můj vlastní, často pracně vyladěný konfigurační soubor. takže pokud už by měla instalace balíčku něco měnit, tak pouze přidávat nové volby v nějakém post-install scriptu. případně vytvořit nový, např. s příponou .new jako to (většinou) dělá pacman z archlinuxu. Je pak na adminovi, aby to prošel.
Prominte ze zasahuji do vasi debaty, ale jiz to tu jednou bylo nastineno, provozujeme promethea ke vsi spokojenosti na pc kde mame i web a dela nam problemy omezovani lan - pokud neni v hosts ip - omezi ji to taky - coz tu jiz jednou bylo receno.
Tak bych s dovolenim rad poprosil, kdyz uz se tu prometheus takhle pitva - jestli by neslo omezovani lan nejak vyrusit, aby to omezovalo jenom wan.
Jako lajk bych si to asi predstavoval tak, ze to co prochazi - forward se omezi a to co prichazi z lan a konci na ipadrese kde je prometheus se neomezi.
Tesim se az jak tu bylo receno, ze se prometheus bude nacitat z databaze - mame trochu slozitejsim zpusobem jiz tohle udelane, ale je to moc prikazu nez se nam vygeneruje hosts.
Jako uzivatel promethea preji vyvojarum mnoho uspechu ve zlepsovani promethea.
neomezuješ forward ... jediné, co lze omezit, nebo řídit je OUTPUT.
Jestli tě dobře chápu, tak ti jede pomalu ten samý stroj ... bys musel udělat něco jako háček ... nadefinuj si LAN vejš, než je skutečná internetová linka a u klientů v hosts si "ručně" zajisti, že ti nikdy nevezmou dohromady víc, než je internet (a ten stroj nastav na zbytek). Ale pravděpodobně to nepojede dobře ... hlavní classa bude moc vysoko a HTB se bude snažit přidělovat něco, co ve většině případů nebude mít. Vařím trochu z vody, před chvilkou jsem vstával ...
Na gateway by nemělo běžet pokud možno nic jiného, než firewall a qos. Přiděláváš si akorát problémy.
Takhle se ledacos zkoušelo dělat dřív, ale je to prasečina.
Čeho je víc jak cca 1000 kusů, to patří do SQL, to je marný (textové konfigurační soubory mají smysl tak do 100 řádek/položek, mezi 100-1000 je taková zóna nikoho... konfigurační soubor který má víc jak 1000 řádek se už spíš stává dalším "zdrojovým kódem aplikace" ...)
Navenek vypadá LMS elegantně, to jo... ale obávám se, že pod slušivým designem se jaksi neskrývá nic světoborného.
V zásadě zatím jsem měl co do činění hlavně s importem dat do SQL strukturu LMS, a nadšený z toho fakt nejsem.
Připouštím ale, že vývoj kompletního systému tak jak bych si ho představoval já by mohl trvat i několik člověkoroků. (tam jde hlavně o to, že by to byl kompletní open source modulární informační systém pro firmy, který by obsahoval všechny pořádné věci které informační systém má mít - a ISP modul by byl jen z mnoha dostupných modulů pro stejnou databázi zákazníků a zaměstnanců, jiným modulem by mohl být e-shop, apod.)