4936
Server / Re:NSS LDAP se bindne, PAM LDAP ne
« kdy: 19. 09. 2014, 10:31:02 »
nss_ldap je správně nakonfigurované, pam_ldap špatně.
(jaká otázka, taková odpověď)
(jaká otázka, taková odpověď)
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.
4937
Odkladiště / Re:Bitcoin v každodenním životě
« kdy: 19. 09. 2014, 10:23:19 »Dolar za posledních 50 let ztratil 90 % své hodnoty. Já bych si už dovolil tuto situaci nazvat jako že „zcela ztratil hodnotu“.No tak k tomu ti za takovou dobu stačí cca 4.5%ní inflace.
Kód: [Vybrat]
>>> 0.955**50
0.10003882432706206
Ad trvalé uložení peněz, zlato, zlato, zlatoMyslíš to zlato, který za poslední 3 roky ztratilo 36%, nebo nějaký jiný zlato?
4938
Studium a uplatnění / Re:VŠ s minimem Windowsismu?
« kdy: 18. 09. 2014, 12:15:31 »To o psaní vlastního operačního systému - to byla jednoduchá ilustrace právě pro 18letého člověka, který zřejmě špatně chápe, jak fungují univerzity. To, že velká část absolventů FI MUNI by nebyla schopna napsat vlastní OS, není vůbec podstatné.Jde o to, že na FI se prostě neučí (resp. neučily) věci tohodle typu. Tak nemať případné zájemce o studium, kteří by pak mohli být zklamaní.
4939
Studium a uplatnění / Re:VŠ s minimem Windowsismu?
« kdy: 18. 09. 2014, 11:36:49 »Na FI MUNI jsem nestudoval [...] předat ti široké vědomosti potřebné např. k napsání vlastního operačního systému.Proč píšeš o něčem, co jsi nezažil? Za mě se na FI žádný vlastní OS nepsal a předávané znalosti tomu byly na míle vzdálené. "Široké/obecné vědomosti" v podání FI za mě znamenalo např. zhruba vědět, jak se dají dokázat Goedelovy věty o neúplnosti. Teď se to nejspíš už trochu posunulo, nejsem tam, takže nevím.
---
K původní otázce:
FI je/(za mě byla) hodně unixově a OSS-orientovaná. Kromě těch Linuxů a Maců bylo v počítačové hale i pár FreeBSDček a před Macy SGI Indy a SGI Octane (bomba stroje, romanticky na ně vzpomínám
- tj. Irix. Kdesi byla i učebna s nějakými Windowsy, ale moc lidí tam nechodilo, já jsem tam byl za celý studium myslím jednou dvakrát, už ani nevím proč. Doma jsem Windows neměl vůbec.P.S. tvůj přístup nekomentuju, je docela normální, že 18-ti letej člověk si děsně zakládá na tom, že je třeba hoper. Časem budeš mít důležitější starosti
4940
Server / Re:Doporučte monitoring pro SNMP
« kdy: 17. 09. 2014, 17:30:25 »
Super, tohle jsem presne potreboval slyset, uz jsem doma Takze ti vlastne jde o klasicky monitorovani sitovych prvku a serveru, zadne exoticke krabicky, u kterych bys chtel merit janevim prutok vody. A taky vlastne nehledas konkretni reseni konkretniho problemu, ale ptas se tak nejak obecne na nase zkusenosti. Ok, pokusím se přispět troškou do mlýna, snad ti to k něčemu bude
Hele, prvně bych řekl, že to, že jsi četl různý silně protichůdný informace, je v téhle oblasti samozřejmý, protože zkušenosti se odvíjí od toho, jakou přesně situaci ten kterej admin řeší. Např. pokud jsi ISP, tak monitoruješ stabilní infrastrukturu a Nagios je pro tebe super, protože konfiguraci nepotřebuješ zas tak často měnit. Oproti tomu pokud máš nějakej elastickej klaud kdesi na AWSku a přibývají a mizí ti tam servery každých 10 vteřin, tak by ses z Nagiosu vosral... Takže prostě nečekej jednotný názory, spíš si všímej, na jakej typ nasazení se komu kterej sw osvědčil a proč *přesně* (co konkrétně na něm chválí a co ho štve).
Moje zkušenost:
Monitoruju stabilní infrastrukturu s malým počtem položek. Zkoušel jsem různý nástroje a zvolil jsem Nagios, protože se mi na něm líbilo, že jsem byl schopnej pochopit *přesně*, jakým způsobem funguje (prostě jednou za x minut spustí určitý skript, ten vrátí určitý kod, ten se pak hodí do RRD nebo se dá zpracovávat dalším skriptem atd. atd.) - prostě Nagios mi ze všech těch nástrojů přišel "nejunixovatější" - jasně oddělené části, které dělají jasně definované jednoduché ulohy. Takže mi dával nejlepší prostor si jednotlivý části přizpůsobit. Jo a taky není v Javě, to jsem považoval za velký plus
Postupně jsem jednotlivý čísti Nagiosu začal nahrazovat vlastními řešeními a nakonec mi zůstalo jenom jádro (scheduler), který jsem nakonec přepsal taky, takže ted už Nagios nemám, už používám jenom jeho pluginy
Nagios má v základu různý nevýhody, ale celkem všechno se dá překonat, bud pomocí check_mk nebo forků (icinga, schinken), ale jednu věc považuju za fakt velkou koncepční chybu: jednotlivý checky vracejí přímo STAV a kromě něj taky nějaký performance data. To je podle mě špatně. Checky by imho správně měly být koncipovaný jenom jako senzory, který vrací hodnoty a nad nima je pak nějakej vyhodnocovač, kterej řekne, jestli v kontextu ostatních hodnot je to ok nebo ne. Tahle koncepční chyba se pořádně nedá překonat, protože od stavu, kterej vrací check, se odvíjí i rescheduling. Takže dost těžko se dá na Nagios naroubovat nějaká korelace eventů apod. Pokud ji chceš, tak Nagios je slepá ulička. Tohle byl hlavní důvod, proč jsem si ho pro svoje potřeby přepsal. Jinak je to ale hezkej kus sw, žádná pětisetmegová hipsterská pětisetmegová srágora která jenom pro sebe potřebuje spešl cluster
Takze ti vlastne jde o klasicky monitorovani sitovych prvku a serveru, zadne exoticke krabicky, u kterych bys chtel merit janevim prutok vody. A taky vlastne nehledas konkretni reseni konkretniho problemu, ale ptas se tak nejak obecne na nase zkusenosti. Ok, pokusím se přispět troškou do mlýna, snad ti to k něčemu bude Hele, prvně bych řekl, že to, že jsi četl různý silně protichůdný informace, je v téhle oblasti samozřejmý, protože zkušenosti se odvíjí od toho, jakou přesně situaci ten kterej admin řeší. Např. pokud jsi ISP, tak monitoruješ stabilní infrastrukturu a Nagios je pro tebe super, protože konfiguraci nepotřebuješ zas tak často měnit. Oproti tomu pokud máš nějakej elastickej klaud kdesi na AWSku a přibývají a mizí ti tam servery každých 10 vteřin, tak by ses z Nagiosu vosral... Takže prostě nečekej jednotný názory, spíš si všímej, na jakej typ nasazení se komu kterej sw osvědčil a proč *přesně* (co konkrétně na něm chválí a co ho štve).
Moje zkušenost:
Monitoruju stabilní infrastrukturu s malým počtem položek. Zkoušel jsem různý nástroje a zvolil jsem Nagios, protože se mi na něm líbilo, že jsem byl schopnej pochopit *přesně*, jakým způsobem funguje (prostě jednou za x minut spustí určitý skript, ten vrátí určitý kod, ten se pak hodí do RRD nebo se dá zpracovávat dalším skriptem atd. atd.) - prostě Nagios mi ze všech těch nástrojů přišel "nejunixovatější" - jasně oddělené části, které dělají jasně definované jednoduché ulohy. Takže mi dával nejlepší prostor si jednotlivý části přizpůsobit. Jo a taky není v Javě, to jsem považoval za velký plus
Postupně jsem jednotlivý čísti Nagiosu začal nahrazovat vlastními řešeními a nakonec mi zůstalo jenom jádro (scheduler), který jsem nakonec přepsal taky, takže ted už Nagios nemám, už používám jenom jeho pluginy
Nagios má v základu různý nevýhody, ale celkem všechno se dá překonat, bud pomocí check_mk nebo forků (icinga, schinken), ale jednu věc považuju za fakt velkou koncepční chybu: jednotlivý checky vracejí přímo STAV a kromě něj taky nějaký performance data. To je podle mě špatně. Checky by imho správně měly být koncipovaný jenom jako senzory, který vrací hodnoty a nad nima je pak nějakej vyhodnocovač, kterej řekne, jestli v kontextu ostatních hodnot je to ok nebo ne. Tahle koncepční chyba se pořádně nedá překonat, protože od stavu, kterej vrací check, se odvíjí i rescheduling. Takže dost těžko se dá na Nagios naroubovat nějaká korelace eventů apod. Pokud ji chceš, tak Nagios je slepá ulička. Tohle byl hlavní důvod, proč jsem si ho pro svoje potřeby přepsal. Jinak je to ale hezkej kus sw, žádná pětisetmegová hipsterská pětisetmegová srágora která jenom pro sebe potřebuje spešl cluster
4941
Server / Re:Doporučte monitoring pro SNMP
« kdy: 17. 09. 2014, 15:19:53 »viac menej centralny cluster[rypnuti] Co presne si mam predstavit pod pojmem "centralni cluster"? Neco jako "suchou vodu"?
[/rypnuti]Je fajn, ze sis neco o veci precetl, ale naprosto klasicky z toho vubec nevychazis:
1. co se ti teda na tom, co sis precetl, nezdalo? Chybela ti tam nejaka informace a ted se nas na ni ptas? Nebo k cemu ti to precteni teda bylo? Jak se tyka problemu, ktery resis?
2. nepises poradne, co vlastne chces resit. Ono je neco jinyho sbirat data jednou za pet minut z deseti zarizeni v lokalni siti a neco jinyho jednou za sekundu z milionu zarizeni po cele planete...
3. nepises, jaky mas pozadavky - staci ti vedet "vsechna zarizeni jsou ok" (sumarizace binarniho stavu krabicek) nebo potrebujes graficky prehled, nebo chces treba dokonce graf toho, jak se ty hodnoty vyvijely?
4. jak slozita maji byt ta pravidla "kdyz neco, tak posli mail"?
SNMP klienta si v libovolnem dnesnim jazyce (treba v pythonu) napises na cca dvaceti radcich, k cemu teda potrebujes nejaky "monitorovaci system"?
4942
Server / Re:Zahranicni VPS, nginx, pomaly "Receiving" time.
« kdy: 11. 09. 2014, 12:20:54 »Amazon ma ping asi 40ms a centra ma v U.S., Irsku, Asii, NZTen ping kolem 40ms je ale do Irska. A je to dany proste geografickou vzdalenosti.
Porovnani pingu ze serveru umistenym na jizni Morave (takze se tam nemota zadna wifi apod.)
Boston:
Kód: [Vybrat]
# ping us-bos-as11488.anchors.atlas.ripe.net
PING us-bos-as11488.anchors.atlas.ripe.net (192.1.90.2): 56 data bytes
64 bytes from 192.1.90.2: icmp_seq=0 ttl=47 time=107.465 ms
64 bytes from 192.1.90.2: icmp_seq=1 ttl=47 time=107.316 ms
64 bytes from 192.1.90.2: icmp_seq=2 ttl=47 time=107.431 ms
64 bytes from 192.1.90.2: icmp_seq=3 ttl=47 time=107.261 ms
64 bytes from 192.1.90.2: icmp_seq=4 ttl=47 time=107.405 ms
64 bytes from 192.1.90.2: icmp_seq=5 ttl=47 time=107.312 ms
64 bytes from 192.1.90.2: icmp_seq=6 ttl=47 time=107.274 ms
^C
--- us-bos-as11488.anchors.atlas.ripe.net ping statistics ---
7 packets transmitted, 7 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 107.261/107.352/107.465/0.075 ms
Dublin:
Kód: [Vybrat]
# ping ie-dub-as2128.anchors.atlas.ripe.net
PING ie-dub-as2128.anchors.atlas.ripe.net (194.88.241.228): 56 data bytes
64 bytes from 194.88.241.228: icmp_seq=0 ttl=54 time=46.705 ms
64 bytes from 194.88.241.228: icmp_seq=1 ttl=54 time=46.682 ms
64 bytes from 194.88.241.228: icmp_seq=2 ttl=54 time=46.655 ms
64 bytes from 194.88.241.228: icmp_seq=3 ttl=54 time=46.769 ms
64 bytes from 194.88.241.228: icmp_seq=4 ttl=54 time=46.847 ms
64 bytes from 194.88.241.228: icmp_seq=5 ttl=54 time=46.560 ms
64 bytes from 194.88.241.228: icmp_seq=6 ttl=54 time=46.555 ms
^C
--- ie-dub-as2128.anchors.atlas.ripe.net ping statistics ---
7 packets transmitted, 7 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 46.555/46.682/46.847/0.098 ms
Praha:
Kód: [Vybrat]
# ping cz-prg-as25192.anchors.atlas.ripe.net
PING cz-prg-as25192.anchors.atlas.ripe.net (217.31.202.20): 56 data bytes
64 bytes from 217.31.202.20: icmp_seq=0 ttl=58 time=4.062 ms
64 bytes from 217.31.202.20: icmp_seq=1 ttl=58 time=4.067 ms
64 bytes from 217.31.202.20: icmp_seq=2 ttl=58 time=4.090 ms
64 bytes from 217.31.202.20: icmp_seq=3 ttl=58 time=4.074 ms
64 bytes from 217.31.202.20: icmp_seq=4 ttl=58 time=4.003 ms
64 bytes from 217.31.202.20: icmp_seq=5 ttl=58 time=3.974 ms
^C
--- cz-prg-as25192.anchors.atlas.ripe.net ping statistics ---
6 packets transmitted, 6 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 3.974/4.045/4.090/0.042 ms
Podle me dela OP chybu proste v tom, ze nejakej dev server obsluhuje pres pul planety. Proc si to nerozchodit v Praze, v klidecku, s paradni konektivitou a az to bude hotovy, tak to deploynout do US? Uz jenom ten ping do Irska je pro praci pres ssh opruz, do US je to pro interaktivni praci prakticky nepouzitelny.
Vsadil bych boty na to, ze ten receiving time je proste kvuli konektivite, nic vic.
zrovna si s tim hraju, na experimenty staci prihlasit svoji kreditku, provoz 12 mesicu zadax, zatim nekecaliJo, obdobi zadax je v pohode, ale kdyz si spocitas cenu za normalni provoz, tak se dostanes na zhruba dvojnasobnou cenu oproti tomu, co se da zprovoznit s minimeme usili jinde a jinak. AWS v zadnym pripade nebrat, pokud clovek nevyuzije moznosti dynamickyho skalovani. Jenom v takovym pripade ma smysl si priplatit, jinak to zadnej smysl nema.
P.S. jeste pro OP: 30MBps je fakt hodne špatný. Takovej výkon leda zadarmo.
4943
Server / Re:Jak lze na Linuxu řešit následující Windows technologie?
« kdy: 11. 09. 2014, 10:32:31 »Prostě mě to jen zajímá, protože sice hodně vidím do MS technologií, ale do Linuxu skoro vůbec a ze známých mi nikdo odpovědět nedokázal.Moc pěkný téma a pěkně položený otázky, díky za ně.
Kolegové už celkem všechno dobře odpověděli, já bych k tomu přidal jenom to, že z těch otázek je ta tvoje MS-orientace hodně poznat. Na unixoidních systémech je totiž vesměs všechno, na co se ptáš, udělaný nějakým modulárním způsobem, takže otázka, jestli něco jde nebo nejde udělat není otázka, jestli to systém umí, ale jestli jde existující pluginy poskládat tak, aby ten celek měl ty vlastnosti, které od něj požaduješ, popř. jestli jde takový plugin napsat a jak moc náročné to je. Tímhle se unixy na serverech od MS produktů dost odlišují.
Např. celý to AAA je o tom, že:
1. aplikaci/systému něco předhodím
2. aplikace nějak ověří, že to, co jsem předhodil, správně identifikuje nějakou osobu
3. nějak ověří, že identifikovaná osoba má mít přístup k danému prostředku
4. někam zapíše, že k prostředku přistupovala
Ty jednotlivý kroky můžeš dělat spoustou různých způsobů nebo klidně i jejich kombinací, podle toho, co od celku očekáváš. Pokud chceš SSO, můžeš použít Kerberos tickety. Pokud chceš ověřovat proti AD, můžeš použít sambu 4 nebo nss-pam-ldap + rfc2307. Můžeš pomocí PAM modulu generovat při prvním příhlášení HOME uživatele. Pokud chceš, můžeš si klidně napsat PAM modul, který šáhne přes usb na Arduino na kterým musíš namačkat správnou kombinaci klingonských kláves. Fantazii se meze nekladou
Konkrétní příklad: jednou jsem si říkal, že by bylo fajn mít nějaké ne-tragicky-kritické filesystémy šifrované a nemuset zadávat heslo. Beztak už mi běží ssh-agent s klíči, tak proč ho na to nevyužít? Takže to chtělo zamyslet se nad tím, co vlastně chci: generovat heslo pomocí ssh-agenta a klíče. A řešení se našlo: https://gist.github.com/mprymek/10415576
Na unixech to prostě není moc o tom, jestli někde existuje nějaké zaškrtávátko, kterým se ta která funkce zapíná, spíš to chce střízlivě a věcně analyzovat problém a podle toho pak zvolit vhodné řešení
4944
Server / Re:Server ze stolního PC
« kdy: 02. 09. 2014, 17:23:36 »@guru prymek - zrovna vcera jsem kupoval 8GB DDR3 - na vrakaci jsem nezkousel, takze v ksefte za 2000 Kc - kdyz tak doporucte, kde ty Vase vrakace maji ?Rád poradím. Náhodou jsem zrovna koupil bezva kejs Sun Ultra 20 za 2800,- a k tomu jsem zdarma dostal:
* 8GM RAM ECC(!)
* dvoujádrovej Opteron
* jakási deska
* jakejsi disk
* stará ale příjemná klávesnice Microsoft, hezky po staru kliká
* stará zašlá otická myš
* licence Windows 7 Pro (v obchodě cca 3500,-)
Ještě je pořád 6ks k dispozici, takže nech sa páči
http://aukro.cz/pc-sun-ultra-20-workstation-dualcore-win7pro-i4543056688.html4945
Server / Re:Server ze stolního PC
« kdy: 02. 09. 2014, 00:04:41 »Wifi bych v těhle podmínkách ani moc neřešilI když vlastně jestli je to rodinná wifi, na které se děje kdovíco a pohání to APčko za tři stovky, tak to je blbý. Tyhle levný krabičky se pod zátěží umí chovat hodně nevyzpytatelně. Takže do pár metrů kabelu po 7Kč metr bych zainvestoval
4946
Server / Re:Server ze stolního PC
« kdy: 01. 09. 2014, 23:59:35 »
Na VPSkách je na pytel hlavně RAMka a kromě toho to může být lenivý z těžko zjistitelných příčin (propustnost všeho možnýho, interrupty, ...). Půl giga RAM může být na samotný aplikace v pohodě, ale moc si na tom nezacachuješ a v horším případě to půjde do swapu, což je smrt.
Oproti tomu, do stroje, kterej máš pod rukama, si dneska seženeš 8G RAM už málem na vrakáči... celej systém ti prakticky poběží z RAM, nebudeš řešit, že teď je ti tam na chvilku těsno atd. Stejně tak disky - můžeš klidně použít jetý za pusu, když to je v rozumným RAIDu a budeš to zálohovat, můžeš být úplně v klidu. A navíc si tam nahraješ všechnymožný filmy, mp3ky a jánevímco a uděláš si z toho domácí mediání centrum, což narozdíl od VPS ocení i rodina
Problém je samozřejmě konektivita. Wifi bych v těhle podmínkách ani moc neřešil, spíš spolehlivost, upload a rta. I když třeba to slavný AWSko taky nemá ping kdovíjakej
Musíš si to rozhodnout sám, o co ti jde spíš, s tím ti nikdo neporadí.
a v horším případě to půjde do swapu, což je smrt.Oproti tomu, do stroje, kterej máš pod rukama, si dneska seženeš 8G RAM už málem na vrakáči... celej systém ti prakticky poběží z RAM, nebudeš řešit, že teď je ti tam na chvilku těsno atd. Stejně tak disky - můžeš klidně použít jetý za pusu, když to je v rozumným RAIDu a budeš to zálohovat, můžeš být úplně v klidu. A navíc si tam nahraješ všechnymožný filmy, mp3ky a jánevímco a uděláš si z toho domácí mediání centrum, což narozdíl od VPS ocení i rodina
Problém je samozřejmě konektivita. Wifi bych v těhle podmínkách ani moc neřešil, spíš spolehlivost, upload a rta. I když třeba to slavný AWSko taky nemá ping kdovíjakej
Musíš si to rozhodnout sám, o co ti jde spíš, s tím ti nikdo neporadí.
4947
Bazar / Re:Darujete starší či nepoužívaný notebook?
« kdy: 30. 08. 2014, 21:15:38 »15'6 = 15 stop a 6 palcu = 4.72 metruNo dyť psal, že má paní problémy se zrakem.
4948
Bazar / Re:Darujete starší či nepoužívaný notebook?
« kdy: 29. 08. 2014, 14:02:41 »Mirku Prýmku, děkuji za nabídku pomoci. Čerstvě teď zase prožívám 7 tučných let, protože se to zase zhouplo ke druhé zdiTak aspoň že tak. Kdybych někdy něčím mohl pomoct, tak se ozvi, klidně přes PM.
4949
Bazar / Re:Darujete starší či nepoužívaný notebook?
« kdy: 29. 08. 2014, 00:09:48 »Nebo pokud to žebrota není, čím se to liší?Liší se to tím, že žebráci si nekladou podmínky. Ještě jsem neslyšel, že by mi žebrák řekl "Nemáš nějakou korunu? Na jídlo! Ale nechci vepřový, nemůžu papriky a z meruněk je mi blbě".
Obzvlášť pikantní je podmínka "displej bez vad". Běžně vídám lidi, kteří si na ntb vydělali sami a drobné vady přežijí, "vždyť se to používat dá, novej se mi kvůli tomu nechce kupovat". Moje drahocená choť měla ještě nedávno šunku, která nesplňovala snad ani jeden z těch požadavků. Samozřejmě mě to dráždilo a nabízel jsem, že koupím něco normálnějšího. "Proč? Mně to stačí." A stačilo, dokud teda na tom displeji bylo vůbec něco vidět
----
@braqela: chlape, máš můj maximální respekt a obdiv. Když už tady teda máme takový rádobycharitativní téma, je něco, čím bysme mohli pomoct tobě?
4950
Bazar / Re:Prodám BTC
« kdy: 28. 08. 2014, 22:24:00 »Co to znamená?Celá tahle úvaha "coby kdyby" je chybná. Dám ti příklad: když budeš koukat třeba na https://www.google.com/finance na kolonku "trends", každý den tam největší gainer toho dne bude mít dvojciferný růst. Třeba dneska je to 35%. Čili za dnešek jsi mohl z milionu vydělat 350 tisíc dvěma kliknutíma myši. A tahle příležitost ti ušla. A to mluvím o veřejně obchodovaných společnostech. Když bys kouknul na firmy v okolí tvýho bydliště, určitě najdeš několik takových, který během pár let vzrostou na několikanásobek.
Ne vždy je dobré poslouchat zdravý rozum!
Každej den ti "uniká" příležitost pohádkově zbohatnout. Jenže jenom teoreticky: "coby kdyby"... Reálně ti nic neuniká, protože prostě v situaci teď a tady nemáš informace k tomu, abys vychytal jenom ty superrostoucí investice a nenamočil se zároveň do propadáků.
Pokud budeš investice posuzovat optikou informací, který máš ex post, tak se z toho tak jedině zblázníš
