31
Server / Re:Co když ztratím SSH klíč?
« kdy: 29. 01. 2014, 21:11:31 »
... ps: fail2ban jinak taky doporučuji :-) prevence
Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
32
Server / Re:Co když ztratím SSH klíč?
« kdy: 29. 01. 2014, 21:10:08 »
Ahoj,
když ztratíš klíč, tak sis ho především měl lépe hlídat.
Pokud se na ten stroj nedostaneš, protože třeba neznáš heslo, tak boot do recovery a tam už tě to v menu navede, jde tam spustit tuším root console, opravit poškozené balíčky atd. Nevím přesně, recovery jsem nikdy nepotřeboval ;-)
Pokud se k tomu stroji připojíš přes heslo, tak odstranit public key z ~/.ssh/authorized_keys (dle nastavení) a poté restartovat ssh server - nebo celej stroj, to je šumák. Jestli je to možné a připojíš se přes VNC konzoli nebo něco takového, vypni připojení k síti.
Pokud si nejsi jistý, zda už tam někdo něco nevyvádí, můžeš udělat mraky věcí:
- vypiš si všechny procesy (ps -aux)
- zkontroluj syslog, auth.log, další logy
- sleduj/zkontroluj traffic na síti (iptraf)
- zkontroluj uživatele, zda nění nějaký nový o kterém nevíš (zejména /etc/passwd)
- koukni i třeba jestli se nezměnila konfigurace ssh serveru
- atd. atd.
Jestli už máš pocit že se tam děje něco nekalého, nic jiného by ti stejně nezbylo - kromě reinstalace :-)
Dobrý je se proti tomu bránit a předcházet tomu. To například nasazením nějakého monitoringu, který by ti i např. zahlásil okamžitě, když se něco stane, kupříkladu změna souboru /etc/passwd nebo velký počet aktivních procesů atd... Rozhodně bych i nastavil iptables, abych se k serveru dostal jen z domova, práce atp. V případě ztráty totiž pak jen klíč vyměníš a neřešíš.
Další věc, roota bys měl používat jen při instalaci...
Ty rady s druhym klíčem apod... Nesmysl, ba naopak riziko větší díry...
když ztratíš klíč, tak sis ho především měl lépe hlídat.
Pokud se na ten stroj nedostaneš, protože třeba neznáš heslo, tak boot do recovery a tam už tě to v menu navede, jde tam spustit tuším root console, opravit poškozené balíčky atd. Nevím přesně, recovery jsem nikdy nepotřeboval ;-)
Pokud se k tomu stroji připojíš přes heslo, tak odstranit public key z ~/.ssh/authorized_keys (dle nastavení) a poté restartovat ssh server - nebo celej stroj, to je šumák. Jestli je to možné a připojíš se přes VNC konzoli nebo něco takového, vypni připojení k síti.
Pokud si nejsi jistý, zda už tam někdo něco nevyvádí, můžeš udělat mraky věcí:
- vypiš si všechny procesy (ps -aux)
- zkontroluj syslog, auth.log, další logy
- sleduj/zkontroluj traffic na síti (iptraf)
- zkontroluj uživatele, zda nění nějaký nový o kterém nevíš (zejména /etc/passwd)
- koukni i třeba jestli se nezměnila konfigurace ssh serveru
- atd. atd.
Jestli už máš pocit že se tam děje něco nekalého, nic jiného by ti stejně nezbylo - kromě reinstalace :-)
Dobrý je se proti tomu bránit a předcházet tomu. To například nasazením nějakého monitoringu, který by ti i např. zahlásil okamžitě, když se něco stane, kupříkladu změna souboru /etc/passwd nebo velký počet aktivních procesů atd... Rozhodně bych i nastavil iptables, abych se k serveru dostal jen z domova, práce atp. V případě ztráty totiž pak jen klíč vyměníš a neřešíš.
Další věc, roota bys měl používat jen při instalaci...
Ty rady s druhym klíčem apod... Nesmysl, ba naopak riziko větší díry...
33
Server / Re:Do serveru HDD, nebo SSD? Pro a proti
« kdy: 27. 01. 2014, 16:28:25 »odkazovat na 4 roky stary blog o lowcost consumer SSD v kontextu serveru je hovadina.
[/quote]
Takže ty informace jsou absolutně bezpředmětný? Proto jsem psal o tom, že záleží na využití.
34
Server / Re:Do serveru HDD, nebo SSD? Pro a proti
« kdy: 27. 01. 2014, 16:10:59 »
Doporučuji počíst pár článků http://www.root.cz/vyhledavani/?qs=SSD&sa=Hledat zejména doporučuji http://petrkrcmar.blog.root.cz/2010/04/16/proc-u-ssd-disku-pouzivanim-klesa-vykon/
Záleží na tom, jaké využití chcete.
Záleží na tom, jaké využití chcete.
35
Studium a uplatnění / Re:Open source jako reference?
« kdy: 24. 01. 2014, 15:36:53 »
Třeba z mého pohledu. Na GITHubu má kde kdo svoje skriptíky atp.
Je to to samé jako by jsi k CVčku připojil archív se skriptama co jsi dělal.
Důležitý ovšem bude, jak bude tvůj software funkční, efekitivní, originální, zdokumentovaný a kdo jej používá - to je teprve reference v tom správném slova smyslu.
Je to to samé jako by jsi k CVčku připojil archív se skriptama co jsi dělal.
Důležitý ovšem bude, jak bude tvůj software funkční, efekitivní, originální, zdokumentovaný a kdo jej používá - to je teprve reference v tom správném slova smyslu.
36
Software / Re:V čem píšete dokumentaci k produktu?
« kdy: 24. 01. 2014, 15:33:08 »
Ahoj,
záleží také na tom, zda jde o technickou dokumentaci nebo uživatelskou a dle toho zvolit šablony/software pro její generování. U technické dokumentace také v čem je to psaný.
Já sám osobně píšu technickou dokumentaci do firemního Redmine (možnost export do PDF atp.), ale existuje plno automatickýho generování (pro PHP: phpDoc, APIGen, ...).
Pro uživatelskou dokumentaci je úplně jedno kde to bude. Online je to fajn třeba v Confluence od Atlassianu. I ten Redmine je v pohodě.
záleží také na tom, zda jde o technickou dokumentaci nebo uživatelskou a dle toho zvolit šablony/software pro její generování. U technické dokumentace také v čem je to psaný.
Já sám osobně píšu technickou dokumentaci do firemního Redmine (možnost export do PDF atp.), ale existuje plno automatickýho generování (pro PHP: phpDoc, APIGen, ...).
Pro uživatelskou dokumentaci je úplně jedno kde to bude. Online je to fajn třeba v Confluence od Atlassianu. I ten Redmine je v pohodě.
37
Server / Re:Joomla nejde smazat přes FTP
« kdy: 19. 12. 2013, 15:16:27 »
Oprava...
Ne IndexFile ale DirectoryIndex :-)
Ne IndexFile ale DirectoryIndex :-)
38
Server / Re:Joomla nejde smazat přes FTP
« kdy: 19. 12. 2013, 15:14:29 »Pane Krčmář děkuji.
Snažil jsem se to podvést tak, že jsem měl záměr nakopírovat v FTP k tomu běžné statické stránky s tím, že jsem počítal, že by se jako první načetl soubor index.html místo index.php a fungovaly by náhradní stránky.
Ovšem ani to mi to neumožňuje. Některé soubory a adresáře však smazat šly.
Ráno mi AVAST oznámil, že jsou ty stránky opět zavirovány.
Problém je, že řešíme převod té domény a nemáme Auth - ID z důvodu, že na webhostingu odešlo železo kde prý byly údaje, které jsou pro vystavení uloženy.
Ještě, že jsem před více než rokem zřídil další doménu, kde nové stránky bez CMS ( momentálně s vánoční tématikou a přáním klientům ) fungují.
Šéf bude mít radost, že bude muset všem klientům rozeslat informaci o tom, že stránky jenž slouží i k přístupu ( jenom link ) na klientský web jsou na jiné doméně.
- Doufám, že nelehl i mailserver .......
Moc děkuji za pomoc, pokud by vás napadlo ještě něco co by se dalo zkusit budu rád. - Webhoster co se nám o to staral je již zaměstnán jinde a není k zastižení. Zatím nevyřešil ani převod té domény, údajně je potřeba to řešit u notáře.
Zdravím,
postupně.
1) Ohledně index.html a index.php, záleží v jaké pořadí je nastaven IndexFile na serveru. Platí pravidlo, že třeba index.html se načítá jako první i když existuje index.php
2) Pokud vám avast hlásí, že jsou stránky zavirovány, nemusí to být nutně virem na webu, ale pro jistotu zmeňte heslo k FTP, aby vám to tam neprojížděl nějaký robot.
3) K AuthID nepotřebujete nic nikde uložený. Potřebujete jen funkční email, který je uvedený u kontaktu (správce, technický kontakt, atp.) u domény.
39
Vývoj / Re:Proč je Java pomalá a problémová?
« kdy: 15. 12. 2013, 21:19:39 »
Pokud je Java pomalá, je špatně napsaný software, který nejspíš ani v Javě být neměl.
Znám na Javě mraky aplikací, který jedou jak po másle. Nemyslím aplikace na desktop, ale např. DMS Alfresco, na to že je to Java, je to dost rychlý.
Znám na Javě mraky aplikací, který jedou jak po másle. Nemyslím aplikace na desktop, ale např. DMS Alfresco, na to že je to Java, je to dost rychlý.
40
Odkladiště / Re:Napsal jsem sw, jak ho prodat?
« kdy: 23. 11. 2013, 19:00:37 »
Ahoj,
klobouk dolů na tvůj věk. Asi bych to neprodával, jelikož vývojem softwaru to nekončí. Je třeba dokumentace, licenční podmínky atd.
Navíc zda je to lehce implementovatelné na jakoukoliv infrastrukturu.
Myslím si, že to co jsi udělal je až moc specifické na to, aby si to někdo koupil. Většinou tyhle věci děláme na zakázku a to nám bude muset stačit ;-)
klobouk dolů na tvůj věk. Asi bych to neprodával, jelikož vývojem softwaru to nekončí. Je třeba dokumentace, licenční podmínky atd.
Navíc zda je to lehce implementovatelné na jakoukoliv infrastrukturu.
Myslím si, že to co jsi udělal je až moc specifické na to, aby si to někdo koupil. Většinou tyhle věci děláme na zakázku a to nám bude muset stačit ;-)
41
Server / Re:Rozšíření Fail2ban na FTP
« kdy: 21. 11. 2013, 21:27:18 »
Nezapomeň si dát do /etc/fail2ban/jail.conf svojí IP z domova nebo odkud budeš ty jako správce používat nebo testovat FTP, popř. servery v síti. Ušetří ti to pár starostí :-) Pokud to už nemáš.
Kód: [Vybrat]
[DEFAULT]
# "ignoreip" can be an IP address, a CIDR mask or a DNS host
ignoreip = 127.0.0.1 XXX.XXX.XXX.XXX
42
Server / Re:Rozšíření Fail2ban na FTP
« kdy: 17. 11. 2013, 21:38:34 »
To by mělo stačit, ještě jestli más filtr v filter.d složce, ale ten je tam v defaultu.
Po restartu fail2ban uvidíš v logu že filter nastartoval.
tail -n 200 /var/log/fail2ban.log | grep proftpd
Po restartu fail2ban uvidíš v logu že filter nastartoval.
tail -n 200 /var/log/fail2ban.log | grep proftpd
43
Desktop / Re:Gnome-shell spouštění
« kdy: 15. 11. 2013, 22:16:02 »
Vše v pohodě, tak asi normální chování :-)
44
Desktop / Re:Gnome-shell spouštění
« kdy: 15. 11. 2013, 21:40:41 »
Ahoj,
Pošli sem výstup. Nicméně nejspíš o nic nejde, pokud grafický prostředí naběhne, i když po chvilce, tak může i nemusí být problém.
Kód: [Vybrat]
tail -n 500 /var/log/boot.logPošli sem výstup. Nicméně nejspíš o nic nejde, pokud grafický prostředí naběhne, i když po chvilce, tak může i nemusí být problém.
