Příspěvky

1

Odkladiště / Re:Jak by ovlivnil výbuch jaderné bomby na Ukrajině IT sektor?

« kdy: 18. 12. 2014, 12:15:29 »

Dejme tomu, že by čistě teoreticky v době před Vánocemi a nebo na Silverstra vybuchla na Ukrajině jaderná bomba, jak myslíte že by to ovlivnilo IT sektor?

Došlo by například k blokaci přístupu k serverům/hostingům v Rusku a dalších zemích jemu nakloněných (např. Venezuela, Brazílie), připadně zavedla by se i jiná opatření k cenzuře internetu?

Jak by na to reagovaly akcie velkých firem jako Microsoft, Oracle, SAP, Intel? Došlo by k jejich poklesu a nebo naopk růstu?

Co dalšího vás napadá, jaký by lokální jaderná válka na Ukrajině měla vliv na informatiky, nabídku práce, zaměstnanost?

Už nyní je Ukrajina dost mimo dění okolního světa - má trochu jiné starosti. A pociťujete snad, že by se kvůli tomu něco v IT měnilo?

2

Vývoj / Re:Hudba pro programování

« kdy: 30. 11. 2014, 17:36:25 »

Ačkoli jsem kdysi svého času dost hrával v klubech, hrál a poslouchal jsem house, trance. To mi vydrželo dlouho, co jsem začal profi vývoj (nějakých 10 let), tak poslední dobou mi ani tvrdší trance nestačil. Začal jsem poslouchat drum & bass a ten držím tak pevně, že už nepustím nic jiného. Při vývoji musím mít v uších pořádnou rychtu a celkem mi to pomáhá

3

Server / Re:Apache VirtualHosts a pouze jeden SSL

« kdy: 21. 11. 2014, 16:48:11 »

klasika.. SSL je vždy per jedna IP adresa... o žádném jiném řešení nevím, kromě proxy a více serverů

4

Sítě / Re:Potřebuji ještě IPv4 nebo stačí IPv6?

« kdy: 10. 10. 2014, 15:28:06 »

O tomhle je mrtě článků na netu, které vše vysvětlují.
Pokud nebudeme brát v potaz to, že by připojení IPv4 <> IPv6 podpořil poskytoval internetu díky NATu či jiným systémům, tak je zde jednoduché pravidlo.
Klient s IPv4 se připojí jen na zdroje (servery), které jsou také pouze na IPv4. Stejně tak je to u IPv6 - musíte mít zjednodušeně router s podporou IPv6 a také být na IPv6 připojen, aby jste si mohl načíst cokoliv ze vzdáleného zdroje, který je na IPv6.

5

Vývoj / Re:Jak začít s Node.js?

« kdy: 07. 08. 2014, 16:52:12 »

Primárně, oficiální dokumentace api:
http://nodejs.org/api/

Další jsou dokumentace jednotlivých balíčků (ne všechny mají dokumentace, ale hlavní většina ano):
https://www.npmjs.org/

Co se týče samotného programování, mysli na to, že se jedná o Event-driven programming a rozhodně bez pokročilých znalostí javaScriptu bych se do toho nepouštěl.

Samozřejmě, google je plnej tutoriálů, ideálně si vymysli aplikaci na které se to naučíš a dle toho hledej Ideální je textový chat.

6

Server / Re:OwnCloud a alternatívy - "produkčné" nasadenie

« kdy: 25. 07. 2014, 20:05:36 »

php zadnej problem s vykonem nema, klidne obslouzi desitky tisic useru a kdyz uz nestiha, tak ti stejne nepomuze vymena jazyka.

má recht ten kluk... v každém případě, jakýkoliv jazyk to stihne zpracovat (pokud je to dobře napsaný), problém je ten, že to nestačí. Web servery jednoduše nestihnou zpracovat velké množství požadavků v jeden moment. Když jsem něco řešil, tak Apache2 při default konfiguraci nestíhal už 300 požadavků v jednu chvíli. Tím se stane to, že procesy apache se začnou kupit, později se z některých stanou zombie a web server vypovídá totálně službu. V takovou chvíli nezbývá nic jiného, než to mít fakt na 100% cloudu, nebo to balancovat sám (klasika haproxy, heartbeat, replikace db (celkem se mi osvědčila replikace mysql pomocí google tungsten a potom jednoduše mysql-proxy).. no ale to je asi už mimo téma.. jen je potřeba si uvědomit, co to může obnášet, mimojiné.

7

Server / Re:OwnCloud pro produkční nasazení

« kdy: 25. 07. 2014, 16:32:58 »

OwnCloud, něco, co jsme v práci jen jednou zkusili testnout. Error log hned po instalaci začal sypat tunu zpráv. Bugtracker je plnej bugů a rostou místo toho, aby byly řešené rychleji. No nevím nevím, klientovi bych se neodvážil něco takového nikdy dodat. To je ovšem jen můj názor.
Pokud bych stavěl něco jako veřejnou službu a myslel bych to vážně, udělal bych to od nuly sám (s týmem) a to pokud se bavíme o cloudovém uložišti, musí být základna v cloudu a to hlavně data replikovaná geolokačně, výkon rozložený na více hardwaru, než jen na jednom stroji s několika virtuálkama.

8

Distribuce / Re:Linux Mint 17 - Otevírání nastavení při změně jasu

« kdy: 25. 07. 2014, 13:30:02 »

Ahoj,
hlásí ti něco logy, když zkoušíš měnit jas?
"tail -f {log}"

9

Server / Re:Zabezpečení web serveru

« kdy: 29. 06. 2014, 20:42:47 »

Z citace logu vidím běhěm 1 vteřiny několik záznamů, které mají 712 bajtů. Jen z toho co vidím je to za týden nějakých 410 MB.

Jenže ty útoky neprobíhají takhle neustále. Jednou za čas to nějaký bot zkusí a za chvíli přestane.

Poddymenzovaný ten server bude, pokud se takové věci řešit nebudou

Tak proč se ptáš, když všechno víš nejlíp?

Protože díky blokování roboti poznají, že jsou zabanovaný a mnohdy už dál požadavky neposílají.

A jindy je zas pošlou z jiné IP. To sis pomohl

Pokud na server nasadim fail2ban či podobný nástroj a vytvořim pravidlo, bude každá další IP taktéž zablokována. Mě to stojí 5 minut času, nic víc.
Uveďte pádné důvody na základě faktů, proč se takovému problému nevěnovat, aby diskuze měla smysl.

10

Server / Re:Zabezpečení web serveru

« kdy: 29. 06. 2014, 19:17:49 »

- Vytěžuje to jen díky blbému zapisování do logu, což i zbytečně plácá místo na disku

Proč tedy řešíš nějaké blokování místo toho, aby sis nastavil svůj logovací systém, aby toto nelogoval?

Protože díky blokování roboti poznají, že jsou zabanovaný a mnohdy už dál požadavky neposílají.

11

Server / Re:Zabezpečení web serveru

« kdy: 29. 06. 2014, 19:16:25 »

- Server zvládne omezený počet požadavků v jeden moment a docházelo by pak k jeho zahlcování

Až něco takového začne být problém, můžeš to řešit. Do té doby je to zbytečná námaha. Navíc tihle boti obvykle negenerují takovou zátěž, aby ti to muselo vadit. Pokud by ti to vadilo, tak by to samo o sobě znamenalo, že máš ten server poddimenzovaný...

Zavedení věcí typu fail2ban zase můžou vést k tomu, že ti zbytečně narostou firewallová pravidla, což je horší než to, co chceš řešit.

Čili rada: Neřeš neexistující problémy

- Vytěžuje to jen díky blbému zapisování do logu, což i zbytečně plácá místo na disku

To je to samý - kolik místa na disku ti to zaplácne? Týdenní logy tak 10MB? Sere pes...

Jinak pokud by to byl problém, tak to musíš řešit nějakým komplexnějším řešením pro logování. To je dost obsáhlý téma, který by sis musel nastudovat...

Z citace logu vidím běhěm 1 vteřiny několik záznamů, které mají 712 bajtů. Jen z toho co vidím je to za týden nějakých 410 MB.
Poddymenzovaný ten server bude, pokud se takové věci řešit nebudou. Ovšem vy jste jiného názoru, nevadí

12

Server / Re:Zabezpečení web serveru

« kdy: 29. 06. 2014, 17:32:42 »

Co přesně byste na tom chtěl "ošetřovat"? Klient požádal o soubor, server zjistil, že takový soubor neexistuje, zapsal to do logu a vrátil  klientovi informaci, že takový soubor neexistuje nebo že k němu nemá přístup. Co vám na tom vadí?

Třeba:
- Server zvládne omezený počet požadavků v jeden moment a docházelo by pak k jeho zahlcování
- Vytěžuje to jen díky blbému zapisování do logu, což i zbytečně plácá místo na disku

13

Server / Re:Zabezpečení web serveru

« kdy: 29. 06. 2014, 16:17:18 »

PS: http://www.fail2ban.org/wiki/index.php/Apache#PHP

14

Server / Re:Zabezpečení web serveru

« kdy: 29. 06. 2014, 16:13:07 »

Nainstaluj si fail2ban a vytvoř v něm pravidlo pro zablokování IP pokud se z ní v logu objeví třeba 10 chybných požadavků během 10 vteřin.

15

Server / Re:Připojení síťového disku pro zápis

« kdy: 29. 06. 2014, 13:37:45 »

Zdar,
nebylo by lepší to hnát přes NFS?
SSH se na to vůbec nehodí, SMB by nemělo co dělat mezi systémy, které běží na Linuxu (dle mého).