=== elzapp_ is now known as elzapp [10:03] Jeg har et nettverk med 14 hp procurve svitsjer, hvilken service bør jeg titte på om jeg vil se samlet SNMP informasjon fra alt utstyr? [10:03] et levende webinterfjes hadde vært å foretrekke [10:03] kva meiner du med "SNMP informasjon" ? Munin er fin for porttellar, t.d. [10:04] Jeg kan sette opp alle svitsjene til å sende SNMP til en server, så noe som kan samle og konvertere dette til noe synlig i nettleseren tenkte jeg på [10:06] noe som kan samle feilmeldinger i tillegg til ytelse [10:08] ah, SNMP traps, det er noko anna [10:08] då er du prisgitt kva svitsjane gir traps for [10:08] men link-brot og slikt er jo vanleg [10:08] ah, takk for oppklaring xt [10:09] SNMP (GET) er innsamling av info, du er jo prisgitt produsent der òg, men pakketeljarar er rimelig standard på alt nettutstyr [10:10] eg trur cacti er populær òg [10:10] Sånn sett bort frå at det er alt for omfattande så har du jo NAV [10:12] https://nav.ntnu.no/about/ [10:14] molven: vil du han verkeleg så vondt? (: [10:14] xt: Eg hadde disclaimer fyrst! [10:14] :) [10:15] hva er disse .mib filene som blir nevnt i ny og ne rundt emnet? [10:15] SlimG: tenk xls for xml (: [10:15] ikkje heilt [10:15] men det er definisjon av kva som finst, og kva det betyr [10:15] og så er det gjerne ulike mibs for snmp get og snmp traps [10:16] ah, ok [10:31] finnes det noe cli verktøy for å gi en grei oversikt på en SNMP trap? [10:31] Du har han snmpwalk. [10:31] Ah, du sa traps? [10:32] tcpdump? (-: [10:32] SlimG: ein snmp trap er berre UDP-pakke sendt frå ei maskin til ei anna [10:32] ca [10:32] (Om du ikke er happy med snmpd, altså.) [10:33] ah, da har jeg misforstått, tenkte snmp trap var den maskinen som var satt opp som snmp server på alle svitsjene [10:34] snmptrapd finst [10:34] eg har brukt den i samspel med http://www.snmptt.org/ for å logge traps til fil/mirk t.d. [10:39] Kanskje jeg burde se på det. [10:39] Jeg har jo satt opp alle Windowsmaskinene til å sende SNMP-traps når de feiler i pålogging. [10:40] snmptt funker ålreit. Kan oversette oid til tekst, og logge til div. backends [10:41] eg logger til sql, og poller derfrå [10:41] det fine/viktige er at du får den fint til å ignorere traps som er slitsomme [10:41] er mange av dei. (: [10:41] SQL er jo nesten kjekt. [10:41] Så kan man spørre seg frem til ting. [10:42] jeg har kikket litt på couchdb i det siste. Det virker jo nesten enda kjekkere. [10:42] …enn? [10:42] sql. [10:43] apples..melons [10:43] Nei, eid. [10:43] jo-erlend_: CouhDB er ikke en relasjonsdatabase. [10:43] Berge, jeg vet jo det? [10:43] Hvordan kan du da si at den er kjekkere enn SQL? [10:44] tja. Språket virker mye mer fleksibelt, for eksempel. Det finnes helt klart situasjoner hvor SQL er bedre egnet. [10:45] Du gir ingen mening. [10:45] neivel? [10:46] CouchDB representerer data på en helt annen måte enn en SQL-database. [10:46] nettopp. [10:46] Det er to forskjellige måter å tenke datalagring på. Med sine fordeler og ulemper. [10:47] ja? Hva er det du vil frem til? [10:47] Om du har data som passer fint i en relasjonsmodell, vil du antagelig komme best ut av det med SQL, eksempelvis. [10:47] Jeg ser ikke hvordan SQL kan være mindre fleksibelt? [10:47] du kan presse alt inn i en relasjonsmodell. Men hvis du snur på det; hvis du _ikke_ er avhengig av kaskader og slikt, så kan dokumentmodellen gjøre ting veldig mye enklere. [10:48] Og mye vanskeligere (-: [10:48] Avhengig av problemet. [10:48] hæ? Hvordan det? [10:48] åja, sånn. Ja, i noen sammenhenger, så kan det det. [10:50] spørsmålet er jo om han trenger støtte for svære kaskader for bruken sin da. [10:50] For øvrig er vel ikke CouchDB kjent for ytelse? [10:50] jojojo. [10:51] folk snakker jo om å bytte ut MySQL for CouchDB nettopp for å få større ytelse og bedre skalering. [10:51] "folk" [10:51] «MySQL» [10:51] Jeg tror ikke jeg kjenner noen som har couchdb i produksjon (-: [10:51] jaja. Alt er relativt. Og hvis du trenger svære kaskader, så er nok en god SQL server et bedre valg. [10:52] Berge, Ubuntu One? [10:52] Jeg kjenner ikke dem som driver Ubuntu One. [10:53] neinei. Jeg misforsto visst. Jeg trodde han snakket om en helt enkel database. [11:54] * virtuelv ser couchdb-diskusjonen i backloggen og klukkler [11:54] virtuelv++ [11:55] http://nosql.mypopescu.com/post/1016320617/mongodb-is-web-scale [12:33] virtuelv, hehe [12:46] jeg mener jo fremdeles at javascript er et mer fleksibelt språk enn SQL. Det er litt mer behagelig også. Men det er lov å være uenige, såklart. [12:48] huuuh? [12:48] hva? [12:50] sense you are not making [12:50] SQL er ett språk. JavaScript er et annet språk. Jeg liker bedre å jobbe med sistnevnte enn førstnevnte.. Hva er vanskelig? [12:51] ja, og eg likar betre å jobbe i nynorsk enn å jobbe i perl [12:51] hmm? [12:51] that's what I was thinking! [12:51] :-D [12:51] jeg visste ikke at hverken perl eller nynorsk ble brukt for å jobbe med data i en database.. :) [12:51] xt: var noe sånn jeg tenkte her og [12:52] jo-erlend_, du endra uanset argument frå "mer fleksibelt" til "bedre å jobbe med" [12:52] begge argument er verdilause i mine auge [12:52] hehe [12:52] endret? Nei. Jeg har ikke endret noen ting. [12:52] bedre å jobbe med = subjektivt, mer fleksibelt = so? [12:52] JavaScript er et mer fleksibelt språk enn SQL. Det kan du nesten ikke være uenig i? Når du snakker om databasene, så er det noe annet. [12:53] Eg sa aldri at eg var uenig [12:53] eg sa det ikkje ga meining. [12:53] jeg synes couchdb er mer praktisk enn å jobbe med en sql database. Det er selvsagt forutsatt at du ikke bevisst prøver å finne et eksempel hvor en SQL database er det eneste som virkelig funker. [12:54] en relasjonsdatabase, mente jeg å si. [12:57] eg logger til sql, og poller derfrå <-- det der så ikke ut som en situasjon hvor du virkelig trenger mange relasjoner. Det var altså i den sammenhengen at jeg veldig kort nevnte at: jeg har kikket litt på couchdb i det siste. Det virker jo nesten enda kjekkere. [12:58] sånn bortsett i frå at ca ingenting støtter det [12:58] hva mener du med det? [12:58] om det var min spesifikke case du ville løyse [13:03] ville egentlig ikke løse noe som helst. Det var bare en kort kommentar. Men hva mener du med at ingenting støtter det? [13:20] jo-erlend_: poenget er at å sammenlikne javascript og sql er som å sammenligne sportsbiler med tankskip [13:21] hvorfor det? JavaScript er spørringsspråket i couchdb, mens SQL er spørringsspråket i SQL-databaser. Da blir det jo temmelig merkelig å ikke sammenlikne språkene hvis du skal sammenlikne bruken av databasene. [13:22] og jeg mente ikke å si at SQL er et dårlig språk, på noen som helst måte. Det får jobben gjort. Men det er ikke et behagelig språk å jobbe med, spør du meg. [13:22] komfort er ikkje eit teknisk argument [13:25] jo-erlend_: Jeg synes SQL er kjempegreier. [13:26] * xt likar nynorsk, og sportsbiler, og tankskip [13:26] Berge, jeg skjønte det. Og i mange sammenhenger er det vel nærmest uslåelig. I endel andre sammenhenger, gir en SQL database deg mer kompleksitet og dårligere ytelse, uten at du egentlig tjener noe som helst. [13:28] Det er uslåelig når du skal, eh, spørre en SQL-database. [13:28] Sånn utover det er det ganske ubrukelig. [13:29] Og, vel, overhodet ikke sammenlignbart med Javascript. (For øvrig, jeg trodde man spurte mot couchdb med noe JSON-greier over HTTP?) [13:30] Berge: JSON er per def javascript :D [13:30] men ikkje eit språk, iofs [13:30] JSON er kun "objekt" [13:30] men det gyldig js-syntaks [13:30] xt: en representasjon, ja? [13:30] Du kan jo jokke med JSON fra perlen din. [13:30] Sånn om du vil. [13:30] JSON er gyldig js-syntaks, men tolkes ikke som javascript. [13:30] Sånn iofs. [13:30] du bruker javascript for å definere visninger. Men Couchdb er jo mye mer enn bare en database. Du kan kjøre programmet ditt direkte på databasen. [13:31] jo-erlend_: I den grad du vil det. [13:31] Du kan sikkert definere javascript-view i andre db-produkt òg [13:31] det har framleis ikkje noko med SQL å gjera, imo [13:32] xt: Sant, sant. [13:33] ja, det er jo tydelig at dere går inn for å misforstå. :) [13:33] nei, du [13:34] altså, hvis to språk brukes på samme måte for å gjøre de samme tingene, så er vel de to språkene sammenliknbare? Spørsmålet er om du har behov for en relasjonsdatabase eller ikke. [13:35] (For øvrig kan du selvsagt vippe inn JSON i Postgresen din, og du kan kjøre perl i den om du føler SQL ikke er tingen for deg.) [13:36] jepp, så då blir alle jo-erlend_ sine poeng ugyldige, [13:36] lett! [13:36] bra, Berge [13:36] \o/ [13:36] Berge, du behøver ikke å definere datatyper og slikt i PostgreSQL? Jeg trodde det var absolutt nødvendig. [13:36] jo-erlend_: Klart. Datatypen JSON. [13:36] just så [13:37] I disse dager kan planneren planlegge spørringer inn i XMLen og JSONen og greier, dog. [13:38] ja, det er mange som snakker varmt om postgres. [13:39] men det er jo SQL, så er nok lite komfort og/eller fleksibilitet :D [13:39] og praktisk [13:39] som var dei tre argumenta dine for couch [13:39] <3 Postgres. [13:39] (Min store, gylne hammer.) [13:39] ♥ MySQL [13:39] * Berge kaster en MyISAM-tabell på xt. [13:39] xt, du har selvsagt lagt merke til at jeg aldri har sagt at couchdb var bedre? [13:39] En tung. [13:40] jo-erlend_, jepp. Og du la sjølvsagt merke til at eg aldri hevda at "SQL" var betre? [13:40] Berge, My ISAM is bigger than yours [13:41] xt: Godt, godt. [13:41] Hehe, fin diskusjon. Min oppfatning: 1) velg teknisk løsning ut fra behov. Dette kan innimellom være så enkelt som en flat fil. 2) Lær deg å bruke den tekniske løsningen du har valgt. Om man må bruke SQL eller Javascript bør komme laaaaangt ned på kriteriumslista :) [13:41] maneatingduck3: altfor sakleg, vonar du angrar no. [13:42] maneatingduck3, enig. [13:43] det var jo ikke det diskusjonen handlet om heller. Spørsmålet var om couchdb er mer praktisk hvis du skal ha en liste du henter elementer fra. I sånne sammenhenger, for min del, er det ingen tvil om at couchdb virker mer praktisk. [13:43] xt: Jau, angrar som ein hund [13:43] jo-erlend_, søte argument [13:44] relevant? nei [13:44] er det ikke? [13:44] http://www.google.com/search?q=couchdb+data+loss [13:44] jo-erlend_: kva som _for deg_ virker meir praktisk, er ikkje relevant, nei [13:45] /dev/null er det raskeste stedet å sende data dersom du ikke bryr deg om å få dem tilbake :) [13:45] maneatingduck3, jeg er klar over det. Det er en umoden teknologi. Jeg har heller aldri anbefalt den løsningen for noen. Jeg synes likevel at løsningen er lovende, praktisk og behagelig. [13:46] handlelister er lovende, praktisk og behagelige [13:46] kan hente elementer frå den lista òg [13:48] * Berge henter xt fra en liste [13:48] * Berge relaterer xt til nynorsk. [13:52] heh, det er forøvrig veldig merkelig hvor mye som kan komme ut av en så liten og ubetydelig kommentar. [13:53] jo-erlend_, nei, det er ikkje pga av den eine [13:53] er summen [13:53] KASKADER [13:53] av rare argument [13:53] som relaterer til kvarandre [13:54] ja, dere er flinke til å misforstå. [13:54] Berge har jo gjort det til en kunst. [13:54] eg føler det som om det er du som misforstår [13:55] Berge misforstår ikkje meg, virker det som, heller [13:55] xt og jeg forstår hverandre ganske godt, egentlig. [13:55] Tross språkbarrieren! [13:56] Berge, ja, kanskje dere ikke vrir like mye på ordene til hverandre. [14:37] vrir på ord? gjorde me det, Berge ? [14:37] xt: Jeg tror ikke jeg vridde på dine ord, i alle fall. [14:40] Wrt ieve nyyr zvar beq 13 unxx [14:41] noen ganger 26 også [14:41] Selv benytter jeg alltid rot26 for dobbel sikkerhet [14:41] I see what you did thar [15:09] jeg leste igjennom backloggen en gang til. Det var vel feil å si at dere vridde på ordene. Det var vel heller sånn at jeg overvurderte dere litt og at det skapte misforståelser. Beklager. [15:10] * Berge undervurderer xt litt for å veie opp. [15:10] * xt overvuderer seg sjølv litt for å vege opp [16:55] hehe, det skjer skikkelig rare ting med ubuntu om dagen. Spesielt Totem. [16:56] nå tok plutselig filmområdet i totem over en fane i firefox, helt uten videre.. Hørt om noe sånt før, eller? [16:57] ah. Nevermind... Jeg må ha klikket og dratt. Visste ikke om den funksjonen jeg. [20:46] Jeg har en bunch med openwrt kapable rutere, hvilken programvare bør jeg ha om jeg ønsker å ha et sentralt lager med brukere, og WPA2 Enterprise? [20:46] Jeg er sett meg litt blind på RADIUS, LDAP, databaser og EAP [20:51] noen som er interessert i å hjelpe meg å flytte brikkene på plass? Laptop <--WPA2Ent@802.11G--> openwrt med ? <--?@ethernet--> Ubuntu server med ? [21:22] SlimG_: windows 2003? :p [21:22] windows 2008, kanskje [21:35] * SlimG_ holder seg for ørene [21:36] Funker dårlig i textchat :) [21:51] Prøv å glem at jeg nevner WPA2Enterprise, jeg er bare interessert i at wifibrukere må autentisere seg med brukernavn+pass for å få koblet til openwrt ruteren, så får openwrt ta spørringen videre til en server med en brukerbase på [21:53] Jeg har kun vært borti wifi rutere med PSK til nå [21:54] Jeg får anbefalt å bruke radius med openldap som backend, men er det nødvendig å bruke radius når man har openldap? i min teori virker radius som en omvei [21:59] SlimG_: hm.. det vanlege er at AP-en spør ein radius-server [21:59] kanskje du kan jukse sidan du kan køyre autentisering lokalt på AP [21:59] men har ikkje testa noko slikt personleg [21:59] bør jo vera gode howtos på dette for wrt? bruker å vera mykje info (: [22:07] det er veldig mange gode howtos som nevner radius, eg må berre bli litt meir klok på kva alt er, så eg veit kva eg vil ha og kan sjå etter riktig howto [22:08] takk for info xt [22:08] npn [22:09] SlimG_: kvifor vil du har user/pass ? er jo stress [22:09] lettere å sette opp hotspot, hehe [22:09] med webside-autentisering [22:09] også støtta på wrt [22:11] Regner med det fungerer dårlig når man vil koble til hodeløse enheter