[PHP] Performance m.b.t. SSH2

[Verwijderd]

Binnen ons CRM heb ik met een collega een module gemaakt die de statussen van onze servers checkt. Wij zijn een kleine ICT dienstverlener met o.a. voip diensten, dus het is vrij cruciaal dat wij snel op de hoogte zijn als er een server down is.

De module werkt als volgt. Elke server heeft een aantal services (het gaat hier om alleen Linux servers), zoals bijvoorbeeld mysqld, httpd, asterisk, hylafax, etc.....

Er draait elke 10 minuten een cronjob die via SSH2 inlogt op al deze servers.

Deze cronjob doet het volgende:

• Hij vraagt de gegevens van al onze servers op (ip, port, username, password, alias, etc), die in een mysql tabel staan
• Vervolgens word er verbinding gemaakt via SSH2
• Vervolgens worden alle services opgevraagd die bij deze server horen
• Het commando /etc/init.d/$service status wordt uitgevoerd, aan de hand van de return waarde wordt de database geupdate
• Per service die niet (meer) draait, zal er een SMS gestuurd worden. De tabel wordt geupdate zodat we niet elke keer als de cronjob draait weer een SMS zullen ontvangen, anders worden we dood gespamt (cron draait elke 10 min)

Al met al een flinke klus, aangezien we op dit moment 15+ servers hebben met elk gemiddeld 5 services.

Het probleem. Ik heb max_execution_time op 300 staan , en nog exceed hij dit af en toe (dus niet elke keer).

Wat kan ik hier nou aan doen? Simpelweg max_execution_time nog hoger zetten? Het is een dedicated server voor ons CRM systeem, dus in principe zou dit geen kwaad moeten kunnen? Is er wellicht nog een andere manier om de performance van dit script te optimaliseren?

Alvast bedankt voor het meedenken.

[r0b]

Waarom niet gewoon een socket openen naar de betreffende service?
Of zit het allemaal achter een firewall en kan je er vanaf de server niet bij?

Ik geloof dat er recent nog een topic was hierover - in WOS; klik - waar dat ook bediscussieëerd werd; uitslag was geloof ik een client/server model.
Iets waar ik persoonlijk weer wat op tegen heb, maar vooruit.

offtopic:
Je slaat dus dus de volledige ssh gegevens op in een database? En aangezien ze later automatisch opgepikt worden zijn ze ook niet encrypted? Kan je niet beter met ssh authorized_keys gaan werken in dat geval? Zeker als er op die wijze klantgegevens achterhaald kunnen worden..

edit:
En misschien ook een aparte (restricted) user aanmaken hiervoor?

[ Voor 36% gewijzigd door r0b op 17-06-2009 13:12 . Reden: Linkje naar topic toegevoegd ]

[Verwijderd]

r0b schreef op woensdag 17 juni 2009 @ 13:05:
Waarom niet gewoon een socket openen naar de betreffende service?
Of zit het allemaal achter een firewall en kan je er vanaf de server niet bij?

Dat zal ik even met mijn collega moeten overleggen, die meer verstand van dat soort zaken heeft. Ik ben maar een code monkey .

[ Voor 18% gewijzigd door Verwijderd op 17-06-2009 13:37 ]

[Verwijderd]

r0b schreef op woensdag 17 juni 2009 @ 13:05:

offtopic:
Je slaat dus dus de volledige ssh gegevens op in een database? En aangezien ze later automatisch opgepikt worden zijn ze ook niet encrypted? Kan je niet beter met ssh authorized_keys gaan werken in dat geval? Zeker als er op die wijze klantgegevens achterhaald kunnen worden..

edit:
En misschien ook een aparte (restricted) user aanmaken hiervoor?

offtopic:
De ssh2 gegevens staan in een database, ja. Ze zijn op dit moment in nog geen enkele vorm encrypted en op dit moment loggen we nog in met het root account (ssh2_auth_password). Het is uiteraard de bedoeling om een vorm van encryptie over de wachtwoorden heen te gooien en vooral niet onder het root account in te loggen. Bedankt voor het meedenken iig , het systeem is nog niet in de productiefase

[ Voor 3% gewijzigd door Verwijderd op 17-06-2009 13:14 ]

[roeleboel]

En als je nu eens op die 15 servers een lokale cronjob draait die de services checkt, en dat output naar een file die (beveiligd) via het netwerk te benaderen is? (samba, http, nfs, ssh, ... take your pick)

Verder kan je perfect een aparte user aanmaken met enkel het recht om die file uit te lezen, zodat je je daar later geen zorgen over moet maken qua security.

[Verwijderd]

Hier de collega van Jesper P.

Wat betreft de cronjob op iedere server, hier is in de beginfase ook aan gedacht en vrij rap al afgekeurd.
Reden hiervoor is dat je in plaats van een 'single point of failiure' naar meerdere points gaat.
Op iedere server moet een cronjob aangemaakt worden, een apart script voor iedere server (aangezien het verschillende services zijn die gecontroleerd moeten worden) en een SMB-achtige constructie waardoor de file beschreven kan worden.

Kortom creëer je dan een situatie waar op iedere server de potentie aanwezig is om onbetrouwbare resultaten te krijgen, liever kiezen wij dan voor een situatie waar één centrale dedicated server deze taak uitvoerd door in te loggen via SSH(keys gaan we inderdaad voor in de volgende fase).

Als reactie op de post van Rob, niet iedere service op de server heeft een socket. Deze oplossing zou dus niet voor iedere service toepasbaar zijn, hierdoor krijgen we dus niet één centrale oplossing.. maar meerdere kleine applicaties die dit afhandelen.

Kortom is het een lastige situatie, op zich denk ik dat de huidige oplossing de meest toepasbare zal zijn.. helaas is door het vele aantal servers/services de execution time nogal lang, soms tot wel meer dan 3/4 minuten.

Input word nog steeds op prijs gesteld in ieder geval :)!

[moozzuzz]

Kan je de cronjob geen 15 jobs laten lanceren die elk één server benaderen?

[Verwijderd]

Lijkt me nogal omslachtig om 10 keer hetzelfde script uit te voeren met wat verschillende parameters, zeker om dit dynamisch te maken met het aantal servers/services is dit lastig uitvoerbaar.

[Verwijderd]

moozzuzz schreef op woensdag 17 juni 2009 @ 13:55:
Kan je de cronjob geen 15 jobs laten lanceren die elk één server benaderen?

Zoals collega J4zen al zei is dit veel te omslachtig Binnen het CRM is er een menu optie aanwezig waarin we servers kunnen beheren (toevoegen, verwijderen, wijzigen) en services aan deze servers kunnen koppelen. Om per server een bestand te moeten maken die ook weer aangepast moet worden lijkt mij niet handig.

[ Voor 4% gewijzigd door Verwijderd op 17-06-2009 14:03 ]

[RAJH]

Je zou ook voor een andere taal met multithreading support kunnen kiezen. Dan kun je bijvoorbeeld 10 servers tegelijk gaan controleren.

[Verwijderd]

RAJH schreef op woensdag 17 juni 2009 @ 14:03:
Je zou ook voor een andere taal met multithreading support kunnen kiezen. Dan kun je bijvoorbeeld 10 servers tegelijk gaan controleren.

Dan moet er speciaal een nieuwe applicatie voor op gezet worden Het liefst houden we alles centraal, als dit mogelijk is uiteraard. Wat we nu hebben is op zich prima, alleen is de performance gewoon niet goed genoeg.

[Wolfboy]

Eventjes een kleine vraag, waarom gebruik je hier geen snmp voor? Dat is hier toch veel geschikter voor?

Vooral aangezien je dan minimale wachttijden zou hebben.

[Verwijderd]

Kun je niet beter nagios gebruiken voor jouw doeleinden? Ik bedoel met nagios kan je zo'n beetje alles monitoren en op de hoogte gehouden door sms, mail, webinterface, irc etc etc. Op tweakers loopt al een tijdje een nagios topic: [Nagios] Ervaringen, scripts en tips

[Wolfboy]

Verwijderd schreef op woensdag 17 juni 2009 @ 14:14:
Kun je niet beter nagios gebruiken voor jouw doeleinden? Ik bedoel met nagios kan je zo'n beetje alles monitoren en op de hoogte gehouden door sms, mail, webinterface, irc etc etc. Op tweakers loopt al een tijdje een nagios topic: [Nagios] Ervaringen, scripts en tips

Of in die trend zijn Zenoss en Zabbix ook nog prima opties.

[Verwijderd]

Wij willen dit graag integreren in ons support panel, aangezien we maar simpel enkele services willen controleren lijken oplossingen als Nagios e.d. nogal overkill. Ik moet eerlijk zeggen, ik heb nooit een volledige implementatie uitgevoerd van deze applicaties.

De situatie waar een multithreaded applicatie de query's uitvoert zou een potentiële oplossing kunnen vormen, liever blijven we echter wel in één taal/applicatie zoals PHP.. maar ik kan me voorstellen dat deze simpel niet toereikend is voor onze toepassing.

[JayVee]

Verwijderd schreef op woensdag 17 juni 2009 @ 13:13:
[...]

offtopic:
De ssh2 gegevens staan in een database, ja. Ze zijn op dit moment in nog geen enkele vorm encrypted en op dit moment loggen we nog in met het root account (ssh2_auth_password). Het is uiteraard de bedoeling om een vorm van encryptie over de wachtwoorden heen te gooien en vooral niet onder het root account in te loggen. Bedankt voor het meedenken iig , het systeem is nog niet in de productiefase

Ik zou een private/public key pair gebruiken hiervoor, dan hoef je de wachtwoorden niet op te slaan.

[vinnux]

Je hebt hele mooie software die dit allemaal kan doen. Het kost wat, maar dan heb je ook wat.
Ik heb goede ervaringen met Intellipool. Hiermee is het o.a. mogelijk om services standaard te laten controleren of eventueel custom scripts gebruiken. Eventueel kan het ook acties ondernemen wanneer een service het niet doet, bijvoorbeeld een herstart, mail etc etc.

Intellipool kan ook output naar file genereren, zodat je die informatie op je eigen manier kunt aanbieden.

(Het lijkt wel reclame)

Uiteraard zijn er veel meer van dit soort programma's. Een gratis/opensource variant is b.v. Nagios/Netsaint.
Eventueel kun je de statussen van Nagios uit de database lezen en integreren in je eigen panel.

Mocht je het toch willen zelf willen ontwikkelen dan zou ik toch gaan voor een robustere programmeer/script taal.

[ Voor 26% gewijzigd door vinnux op 17-06-2009 15:16 ]

[r0b]

Verwijderd schreef op woensdag 17 juni 2009 @ 13:47:
Kortom is het een lastige situatie, op zich denk ik dat de huidige oplossing de meest toepasbare zal zijn.. helaas is door het vele aantal servers/services de execution time nogal lang, soms tot wel meer dan 3/4 minuten.

Hm, je kan misschien nog iets doen door te kijken of er wel of geen pid-file voor de applicatie bestaat, maar ook dat biedt geen zekerheid (helemaal niet als de applicatie gecrasht is zonder de pid-file te verwijderen / de applicatie gewoon unresponsive is).

Misschien een combinatie van alledrie de oplossingen met een fallback naar ssh2 exec als je geen bevredigend resultaat krijgt
Dan haal je in ieder geval al een stukje performance terug.

JayVee schreef op woensdag 17 juni 2009 @ 15:03:
[...]

Ik zou een private/public key pair gebruiken hiervoor, dan hoef je de wachtwoorden niet op te slaan.

Was al genoemd in de 1e reply

vgouw schreef op woensdag 17 juni 2009 @ 15:09:
Je hebt hele mooie software die dit allemaal kan doen. Het kost wat, maar dan heb je ook wat.
Ik heb goede ervaringen met Intellipool. Hiermee is het o.a. mogelijk om services standaard te laten controleren of eventueel custom scripts gebruiken. Eventueel kan het ook acties ondernemen wanneer een service het niet doet, bijvoorbeeld een herstart, mail etc etc.

Uiteraard zijn er veel meer van dit soort programma's. Een gratis/opensource variant is b.v. Nagios/Netsaint.

Verwijderd schreef op woensdag 17 juni 2009 @ 14:47:
Wij willen dit graag integreren in ons support panel, aangezien we maar simpel enkele services willen controleren lijken oplossingen als Nagios e.d. nogal overkill.

[ Voor 43% gewijzigd door r0b op 17-06-2009 15:11 ]

[Bjornski]

In php kun je met proc_open en consorten processen opstarten zonder dat ze jouw thread blokkeren. Ik zou een PHP bestand maken dat je database uitleest en voor elke server in de database een nieuw proces opstart wat het daadwerkelijke uitlezen doet.

Als die scripts dan klaar zijn kunnen ze zelf het resultaat wegschrijven naar MySQL. Elk script (en dus elke server) heeft dan zijn eigen 300 seconden om zijn ding te doen.

Desalniettemin lijkt me een combinatie van SNMP en poorten opentrekken (zoals de reeds eerder genoemde monitoring tools doen) een betere oplossing. Je kunt ook vanuit PHP prima interfacen met bijvoorbeeld nagios.

edit:
typo

[MueR]

Verwijderd schreef op woensdag 17 juni 2009 @ 13:47:
Kortom is het een lastige situatie, op zich denk ik dat de huidige oplossing de meest toepasbare zal zijn.. helaas is door het vele aantal servers/services de execution time nogal lang, soms tot wel meer dan 3/4 minuten.

En die gaat alleen maar langer worden naar mate er meer servers bij komen. Je zal dus moeten kijken naar een oplossing die schaalbaar is, en dat gaat je vanuit een enkel punt niet lukken. Per server een cron inrichten is misschien wat meer werk, maar je omzeilt hiermee wel de diverse limiteringen van PHP (max execution time). Als je dat perse niet wil doen, zal je de check per server moeten gaan uitvoeren. Met andere woorden, je centrale cron elke minuut laten lopen, en elke minuut 1 of 2 servers checken. Dat zou snel genoeg moeten gaan.

[Verwijderd]

MueR schreef op woensdag 17 juni 2009 @ 15:29:
[...]
Als je dat perse niet wil doen, zal je de check per server moeten gaan uitvoeren. Met andere woorden, je centrale cron elke minuut laten lopen, en elke minuut 1 of 2 servers checken. Dat zou snel genoeg moeten gaan.

Ik denk dat dat wel een goede oplossing zou kunnen zijn voor onze huidige situatie, we gaan bekijken in hoeverre dat de performance zal verbeteren.

[Confusion]

Verwijderd schreef op woensdag 17 juni 2009 @ 14:47:
Wij willen dit graag integreren in ons support panel, aangezien we maar simpel enkele services willen controleren lijken oplossingen als Nagios e.d. nogal overkill.

Iets zelf proberen te schrijven wat al goed wordt opgelost door bestaande services lijkt mij overkill. Zeker als je er straks nog iets bijbedenkt, en dan nog iets, dan ben je uiteindelijk steeds meer opnieuw aan het bouwen dat je meteen had kunnen hebben als je gewoon monitoring software had geinstalleerd.

[Tead]

Wat ik ooit eens heb gebruikt in een cronjob script met veel verwerkingen is set-time-limit.

Elke keer als je een nieuw request doet naar een service zet je daar voor set_time_limit(10); De request heeft dan dus een time-out van 10 seconde. Dit zou voldoende moeten zijn voor één request en is lekker schaalbaar. In jou geval zal het script maximaal (15 servers * 5 services * 10 seconde time-out) 750 seconde duren. Bij meer servers/services zal de max uiteraard hoger liggen.

[Verwijderd]

Confusion schreef op woensdag 17 juni 2009 @ 15:44:
[...]

Iets zelf proberen te schrijven wat al goed wordt opgelost door bestaande services lijkt mij overkill. Zeker als je er straks nog iets bijbedenkt, en dan nog iets, dan ben je uiteindelijk steeds meer opnieuw aan het bouwen dat je meteen had kunnen hebben als je gewoon monitoring software had geinstalleerd.

Als iedereen voor die methode blijft kiezen zullen er nooit betere oplossingen op de markt komen Daarbij hebben wij te maken met té specifieke services en interne appliacties om te laten controleren door één generiek softwarepakket.

@tead:
Bedankt, gaan we bekijken!

[Creepy]

J4zen: no offence maar je kent blijkbaar nagios niet Het is enorm eenvoudig om hiervoor eigen plugins te schrijven. Je hoeft je dan ook alleen maar te concenteren op de plugins en niet op het extra volledig framework wat je nu aan het bouwen bent en wat blijkbaar nu al voor problemen zorgt

Nagios heeft alle problemen die je nu hebt (remote host checks, timeouts e.d.) allang goed opgelost. Ik vind het dan ook vreemd dat je niet eens in dit soort systemen hebt verdiept en direct voor zelfbouw kiest.

[Gerco]

Verwijderd schreef op woensdag 17 juni 2009 @ 15:52:
Als iedereen voor die methode blijft kiezen zullen er nooit betere oplossingen op de markt komen Daarbij hebben wij te maken met té specifieke services en interne appliacties om te laten controleren door één generiek softwarepakket.

Natuurlijk, want pakketten als Nagios, Zabbix, etc hebben natuurlijk totaal geen mogelijkheid om een "check_xyz_service" script te runnen op gezetten tijden...

Als je zelf graag iets wilt bouwen is dat prima, maar ga jezelf niet voorhouden dat je dat doet omdat bestaande en bewezen monitoring software dat niet kan.

[u_nix_we_all]

Verwijderd schreef op woensdag 17 juni 2009 @ 15:52:
[...]


Als iedereen voor die methode blijft kiezen zullen er nooit betere oplossingen op de markt komen Daarbij hebben wij te maken met té specifieke services en interne appliacties om te laten controleren door één generiek softwarepakket.

Ik heb zelf wel wat ervaring met Nagios, en om eerlijk te zijn denk ik dat dat juist precies is wat je nodig hebt. Het sterke aan Nagios is dat het redelijk modulair is, en vooral de engine die de checks sheduled en uitvoert doet het erg goed.
Bovendien is er een goed werkend mechanisme met de NRPE (Nagios Remote Plugin Executer) voor remote checks, hierin zit al ssh ingebouwd, en deze is gemaakt om onder een dedivcated user te draaien (en dus niet onder root)

Voor je front-end kun je prima gebruik maken van de stukjes html die nagios je levert, dit kun je prima achter een knop stoppen of de html-code erbij embedden.

Oh, en ik type te traag, Creepy en Gerco waren me voor

[Confusion]

Verwijderd schreef op woensdag 17 juni 2009 @ 15:52:
Als iedereen voor die methode blijft kiezen zullen er nooit betere oplossingen op de markt komen

Don't flatter yourself. Jij gaat in alle valkuilen trappen die de makers van nagios en vrienden al ontweken hebben en je gaat alle bugs in je software stoppen die zij er in -tig iteraties al uitgehaald hebben. Je bent bezig een kwalitatief slechtere oplossing te bouwen, die meer geld kost, minder kan, minder uitbreidbaar zal zijn en waarschijnlijk over een jaar alsnog vervangen gaat worden door een veelzijdig, robust, schaalbaar, veelvuldig in productie getest, monitoring systeem. Je kiest niet de beste oplossing voor je probleem, maar degene die je zelf het leukst vind om uit te voeren. De andere grote oorzaak van het Not Invented Here syndroom.

[ Voor 6% gewijzigd door Confusion op 17-06-2009 16:17 ]

[Verwijderd]

Edit: Er zijn een stuk of 5 replies gepost in de tijd dat ik repliede. Mogelijk dat de onderstaande post het e.e.a. verduidelijkt. Begrijp me niet verkeerd, ik snap dat Nagios een prima oplossing aanbied en het implementatietraject mogelijk zou kunnen verkorten. Ik vind enkel dat het te kortaf gedacht is dat een dergelijke pakket volledig aan onze eis zou kunnen voldoen zonder de onderliggende architectuur en beweegredenen te begrijpen.

Onderstaand mijn oorspronkelijke post:

Ik gaf eerder al aan dat ik inderdaad niet bekend ben met nagios systemen, ik heb er vaker over gelezen maar nooit daadwerkelijk geimplementeerd. Dit met name omdat het standaard niet aan de eisen voldeed. Het plugin systeem ken ik niet, maar ik kan me voorstellen dat ik hier iets van een interface moet schrijven in een bepaalde programmeertaal?

De reden waarom ik bang ben dat een systeem als Nagios niet aan onze eisen zal voldoen is het feit dat we met veel telefonie hardware/software werken en diverse zelfontwikkelde applicaties. Vaak gaan pakketten ontwikkeld voor de massa uit van bepaalde standaarden, dit terwijl wij mogelijk in onze applicaties/hardware hier niet aan voldoen.

Voorbeelden zijn bijvoorbeeld media-gateways, foneBridges, GSM gateways en dergelijke apparatuur. Dit buiten de standaard windows/linux servers. Het word denk ik lastig om nagios-client applicaties hierop te draaien.


Overigens voel ik weinig voor reacties waarin mij verweten word dat ik een onpraktische blik op techniek heb en te maken zou hebben met een "syndroom", gelieve dit simpelweg achterwege te laten.

[ Voor 37% gewijzigd door Verwijderd op 17-06-2009 16:24 . Reden: Wijziging wegens massa replies in korte tijd. ]

[Cartman!]

Mogelijk hier niet aan voldoen..

Dan kun je het toch proberen? Nu sluit je het al min of meer uit zonder het geprobeerd te hebben. Misschien heb je de hele boel binnen n uurtje wel werkend, wie zal het zeggen?

[Verwijderd]

Cartman! schreef op woensdag 17 juni 2009 @ 16:25:
[...]

Dan kun je het toch proberen? Nu sluit je het al min of meer uit zonder het geprobeerd te hebben. Misschien heb je de hele boel binnen n uurtje wel werkend, wie zal het zeggen?

Uiteraard ben ik bereid dit te proberen, dat sluit ik nergens uit. Ik gaf eerder enkel aan dat ik het topic graag open hield van andere suggesties dan een pakket als Nagios

[B0rf]

Als jullie versie van PHP het ondersteund zou je het huidige script ook met de pcntl_fork kunnen omschrijven om meerdere threads te gebruiken. Op deze manier blijf je wel bij een bekend ontwikkelplatform, en heb je de voordelen van multithreading. pcntl zit helaas niet standaard in PHP gecompileerd, dus misschien moet je PHP hercompileren hiervoor. Ook zijn er een aantal functies die misbruikt kunnen worden door 3rd party scripts (als een kwaadwillend persoon op de een of andere manier een uitvoerbaar php-bestand op je server weet te krijgen), en misschien ook dicht gezet moeten worden

[Verwijderd]

B0rf schreef op woensdag 17 juni 2009 @ 16:27:
Als jullie versie van PHP het ondersteund zou je het huidige script ook met de pcntl_fork kunnen omschrijven om meerdere threads te gebruiken. Op deze manier blijf je wel bij een bekend ontwikkelplatform, en heb je de voordelen van multithreading. pcntl zit helaas niet standaard in PHP gecompileerd, dus misschien moet je PHP hercompileren hiervoor. Ook zijn er een aantal functies die misbruikt kunnen worden door 3rd party scripts (als een kwaadwillend persoon op de een of andere manier een uitvoerbaar php-bestand op je server weet te krijgen), en misschien ook dicht gezet moeten worden

Klinkt interessant, gaan we ook naar kijken.

[u_nix_we_all]

Verwijderd schreef op woensdag 17 juni 2009 @ 16:18:
Het plugin systeem ken ik niet, maar ik kan me voorstellen dat ik hier iets van een interface moet schrijven in een bepaalde programmeertaal?

Plugins kunnen shell-scripts, php-scipts, executables etc. zijn. Eigenlijk is alles wat je nu al hebt om ergens een status van op te vragen al bruikbaar, mits je gebruik maakt van exit-codes.

De reden waarom ik bang ben dat een systeem als Nagios niet aan onze eisen zal voldoen is het feit dat we met veel telefonie hardware/software werken en diverse zelfontwikkelde applicaties. Vaak gaan pakketten ontwikkeld voor de massa uit van bepaalde standaarden, dit terwijl wij mogelijk in onze applicaties/hardware hier niet aan voldoen.
Voorbeelden zijn bijvoorbeeld media-gateways, foneBridges, GSM gateways en dergelijke apparatuur. Dit buiten de standaard windows/linux servers. Het word denk ik lastig om nagios-client applicaties hierop te draaien.

No problem, als jij iets kunt schrijven wat je een status geeft (en dat heb je blijkbaar al gedaan), dan levert Nagios een mooi framework die die checks voor je kan uitvoeren.

Overigens voel ik weinig voor reacties waarin mij verweten word dat ik een onpraktische blik op techniek heb en te maken zou hebben met een "syndroom", gelieve dit simpelweg achterwege te laten.

Wellicht roep je dat over jezelf af, door een toepassing die volgens meerdere mensen precies doet wat jij wilt af te serveren met "waarschijnlijk kan dat niet" zonder daar dan eens naar te kijken. Gevalletje van "vraag het dan ook niet"

[Gerco]

Verwijderd schreef op woensdag 17 juni 2009 @ 16:18:
Het plugin systeem ken ik niet, maar ik kan me voorstellen dat ik hier iets van een interface moet schrijven in een bepaalde programmeertaal?

In zowel Nagios als Zabbix moet je een executable of script schrijven in een willekeurige programmeertaal die optioneel argumenten meekrijgt over wat hij moet checken en een waarde moet returnen (als exit waarde of op stdout) waar het systeem verder mee gaat werken.

Oftewel er zit geen enkele limitatie aan die plugins behalve dat ze command line arguments moeten kunnen accepteren en naar stdout kunnen schrijven. Als je een programmeertaal of omgeving kan vinden waarin je wel een SSH verbinding kan opzetten, maar deze requirements niet kunnen vind ik het knap

[Verwijderd]

Nogmaals, ik schrijf nagios niet af.. ik gaf eerder op pagina 1 al aan dat ik het topic open houd voor overige suggesties daar ik niet zeker ervan ben momenteel of nagios dit kan. Ik schrijf niets af.

[Confusion]

Verwijderd schreef op woensdag 17 juni 2009 @ 16:18:
Ik vind enkel dat het te kortaf gedacht is dat een dergelijke pakket volledig aan onze eis zou kunnen voldoen zonder de onderliggende architectuur en beweegredenen te begrijpen.

De reden waarom ik bang ben dat een systeem als Nagios niet aan onze eisen zal voldoen is het feit dat we met veel telefonie hardware/software werken en diverse zelfontwikkelde applicaties.

Dit soort software is juist geschreven met het doel om in allerlei architecturen en met allerlei monitoringsdoeleinden inzetbaar te zijn. Je bent zelden zo uniek als je in eerste instantie denkt. Ik zit hier bij een bedrijf met een groot callcenter. Zij monitoren alles met, jawel, Nagios.

Wat betreft mogelijkheden voor exotische hardware: zie Gerco.

Overigens voel ik weinig voor reacties waarin mij verweten word dat ik een onpraktische blik op techniek heb en te maken zou hebben met een "syndroom", gelieve dit simpelweg achterwege te laten.

Het is niets persoonlijks: het is iets waar iedereen voor op zijn hoede moet zijn. Iedereen denkt snel dat zijn situatie bijzonder is, dat zijn eisen afwijken van de norm en dat bestaande oplossing dus niet bruikbaar zijn. Het is een hele normale gedachte, maar niettemin eentje die vaak ongegrond is. (er is een verschil tussen je motief om ergens voor te kiezen en de rechtvaardiging die je aanvoert om er voor te kiezen: dat een bestaande oplossing niet geschikt is, is een rechtvaardiging, maar nog geen motief).

Not Invented Here (NIH) is a term used to describe persistent social, corporate or institutional culture that avoids using or buying already existing products, research or knowledge

[ Voor 33% gewijzigd door Confusion op 17-06-2009 17:47 ]

[Soultaker]

Ik los dit soort dingen meestal op door een scriptje beschikbaar te maken via inetd. Je PHP script connect dan simpelweg met de goede hostname en port en leest de huidige status uit.

Het mooie daarvan is dat je het ook heel simpel parallel kunt laten uitvoeren: open gewoon eerst sockets naar alle servers en lees ze dan een voor een uit. Je kunt het later eventueel nog mooier maken door met asynchrone sockets te werken zodat je ook parallel kunt verbinden, maar dat is waarschijnlijk overkill.

edit:
Overigens: is het mogelijk eens wat timing informatie te loggen van je script? Ik ben wel benieuwd waar de tijd nu in gaat zitten, want hoewel het opzetten van een SSH verbinding relatief kostbaar is, heb je met vijf minuten voor vijftien servers toch nog (gemiddeld) 20 seconde per server en het opzetten van een ssh-connectie zou in die situatie toch verwaarloosbaar moeten zijn...

[ Voor 29% gewijzigd door Soultaker op 17-06-2009 18:27 ]

[Verwijderd]

Confusion schreef op woensdag 17 juni 2009 @ 17:34:
Het is niets persoonlijks: het is iets waar iedereen voor op zijn hoede moet zijn. Iedereen denkt snel dat zijn situatie bijzonder is, dat zijn eisen afwijken van de norm en dat bestaande oplossing dus niet bruikbaar zijn. Het is een hele normale gedachte, maar niettemin eentje die vaak ongegrond is. (er is een verschil tussen je motief om ergens voor te kiezen en de rechtvaardiging die je aanvoert om er voor te kiezen: dat een bestaande oplossing niet geschikt is, is een rechtvaardiging, maar nog geen motief).

Als ik één regel verder lees dan dat kom ik toch al snel tot de conclusie dat het genoemde syndroom werkelijk totaal niet van toepassing is:

[...]
As a social phenomenon, "Not Invented Here" syndrome is manifested as an unwillingness to adopt an idea or product because it originates from another culture, a form of nationalism.
[...]

Lijkt mij nogal ongegrond.


Wat betreft de timing van de applicatie;

We maken gebruik van de SSH2 module in PHP, helaas is deze nog in Beta en bevat een bug in de ssh2_exec function waarin de applicatie een datastream langer openhoud dan nodig totdat deze uiteindelijk een timeout ontvangt van de server, dit word nu afgevangen door een work-around van ons. Helaas levert dit enkele vertragingen op bij 1 op de 5 requests. De module zelf fixen word lastig, er is uiteraard wel een ticket voor aanwezig.

[Grijze Vos]

Tead schreef op woensdag 17 juni 2009 @ 15:44:

Elke keer als je een nieuw request doet naar een service zet je daar voor set_time_limit(10); De request heeft dan dus een time-out van 10 seconde. Dit zou voldoende moeten zijn voor één request en is lekker schaalbaar. In jou geval zal het script maximaal (15 servers * 5 services * 10 seconde time-out) 750 seconde duren. Bij meer servers/services zal de max uiteraard hoger liggen.

En hoeveel seconden gaan er in 10 minuten? Niet echt een zinnige oplossing als ze elke 10 minuten willen pollen.

[Confusion]

Verwijderd schreef op donderdag 18 juni 2009 @ 08:29:
Lijkt mij nogal ongegrond.

Omdat die zin een specifieke soort beschrijft, die niet relevant is voor de situatie die hier optreedt. Dat je denkt dat de oplossing die een ander heeft geschreven waarschijnlijk niet geschikt is voor jouw bijzondere situatie, is net zo goed NIH. Die term wordt veel in de software industrie gebruikt, en niet omdat men denkt dat er nationalistische motieven in het spel zijn. Het zou fijn zijn als je mijn bedoeling probeerde te begrijpen. Het is voor alle anderen glashelder wat ik bedoel.

Maargoed, ga lekker verder met je eigen herimplementatie... en nu maar hopen dat niemand leestoegang tot je database krijgt he.

[ Voor 9% gewijzigd door Confusion op 18-06-2009 09:21 ]

[Verwijderd]

Confusion schreef op donderdag 18 juni 2009 @ 09:20:
[...]

Omdat die zin een specifieke soort beschrijft, die niet relevant is voor de situatie die hier optreedt. Dat je denkt dat de oplossing die een ander heeft geschreven waarschijnlijk niet geschikt is voor jouw bijzondere situatie, is net zo goed NIH. Die term wordt veel in de software industrie gebruikt, en niet omdat men denkt dat er nationalistische motieven in het spel zijn. Het zou fijn zijn als je mijn bedoeling probeerde te begrijpen. Het is voor alle anderen glashelder wat ik bedoel.

Maargoed, ga lekker verder met je eigen herimplementatie... en nu maar hopen dat niemand leestoegang tot je database krijgt he.

Uiteraard begrijp ik je bedoeling wel, ik ben het alleen niet met je stelling eens.Het interesseert me werkelijk totaal niet welke oplossing we zullen gaan gebruiken zolang het maar aan de vraag voldoet. Dat is het deel dat je weigert op te maken uit mijn reacties. Ik heb dit geloof ik al een keer of vier gemeld maar ik schrijf Nagios NIET af, ik hou (nogmaals) het topic open voor alternatieve methodes om dit probleem te tackelen.

En laten we inderdaad hopen dat niemand leestoegang krijgt tot onze database Een pakket dat ontwikkeld is door derden is per slot van rekening ten alle tijden 100% veilig.

Naar mijn mening is dit een typisch geval "De pot verwijt de ketel dat hij zwart ziet.". Je neemt mij kwalijk dat ik je punt niet bevat, terwijl je al lang uit mijn reacties kan opmaken dat Nagios niet afgeschreven is.

[Grijze Vos]

Ik vraag me dan af waarom jullie al zo druk aan het developen zijn geslagen, als je pakketten van derden niet afgeschreven hebt. Onderzoeken welke software je kunt gebruiken is toch meestal stap 1 zou je denken.

[Verwijderd]

Grijze Vos schreef op donderdag 18 juni 2009 @ 10:10:
Ik vraag me dan af waarom jullie al zo druk aan het developen zijn geslagen, als je pakketten van derden niet afgeschreven hebt. Onderzoeken welke software je kunt gebruiken is toch meestal stap 1 zou je denken.

Klopt, daaruit hebben wij destijds de conclusie getrokken dat een bestaand pakket waarschijnlijk niet overweg zou kunnen met onze hardware en specifieke omstandigheden. In principe is dit een redelijk simpele applicatie met weinig haken en ogen, vandaar dat er niet complete test-implementaties verricht zijn om dit te bevestigen. Daarbij leek het ons minder werk om een dergelijk systeem te ontwikkelen binnen ons framework dan een derde framework te gebruiken, implementeren en integreren in ons CRM.

Ik zou het op prijs stellen als er vanaf nu wat meer on-topic op de originele vraagstelling gereageerd kan worden.

[Confusion]

Verwijderd schreef op donderdag 18 juni 2009 @ 09:55:
En laten we inderdaad hopen dat niemand leestoegang krijgt tot onze database Een pakket dat ontwikkeld is door derden is per slot van rekening ten alle tijden 100% veilig.

Nee, bij gebruik van Nagios e.d. heb je die credentials niet nodig.

Jullie zeggen nu dat dat nog wel gefixed gaat worden, maar de praktijk leert dat als iets werkt, het meestal uitgesteld en afgesteld wordt. Wedje leggen dat jullie straks in jullie productieomgeving ook gewoon alle ssh credentials in plaintext in de database hebben staan? It's an accident waiting to happen.

Verwijderd schreef op donderdag 18 juni 2009 @ 10:14:
Klopt, daaruit hebben wij destijds de conclusie getrokken dat een bestaand pakket waarschijnlijk niet overweg zou kunnen met onze hardware en specifieke omstandigheden.

Hoe kan je uit een onderzoek concluderen dat iets 'waarschijnlijk' niet geschikt is? Dan is dat onderzoek toch pet? Je concludeert dat iets wel of niet geschikt en beslist vervolgens of je het wel of niet wenst te gebruiken, andere factoren meenemende. Je gaat niet van alles implementeren en dan nog eens kijken of je misschien toch niet bestaande software kan gebruiken.

In principe is dit een redelijk simpele applicatie met weinig haken en ogen

Remote allerlei servers/services monitoren is geen simpel probleem.

Daarbij leek het ons minder werk om een dergelijk systeem te ontwikkelen binnen ons framework dan een derde framework te gebruiken, implementeren en integreren in ons CRM.

Als je dat alleen maar denkt en het je alleen maar het geval lijkt en je beslissing dus op die gevoelsgronden genomen is: NIH. In plaats van te blijven herhalen dat je Nagios/Zabbix/... niet hebt afgeschreven: zoek nou eerst eens als de sodemieter uit of het bruikbaar is of niet en schrijf het af als dat niet zo is.

Volkomen ontopic: je probleem is een bug in de PHP SSH library. Wat in vredesnaam wil je verder van ons horen?

[ Voor 53% gewijzigd door Confusion op 18-06-2009 10:55 ]

[u_nix_we_all]

Verwijderd schreef op donderdag 18 juni 2009 @ 10:14:
[...]

Ik zou het op prijs stellen als er vanaf nu wat meer on-topic op de originele vraagstelling gereageerd kan worden.

Je wilt dus dat wij je helpen om jouw oplossing, waarmee je het blijkbaar niet voor elkaar krijgt om 15 x 5 services binnen 10 minuten te controleren ( ! ) , wel aan de gang te krijgen, maar wilt niet horen dat daarvoor veel betere oplossingen bestaan ?

[Verwijderd]

Confusion schreef op donderdag 18 juni 2009 @ 10:40:
[...]

Nee, bij gebruik van Nagios e.d. heb je die credentials niet nodig.

Jullie zeggen nu dat dat nog wel gefixed gaat worden, maar de praktijk leert dat als iets werkt, het meestal uitgesteld en afgesteld wordt. Wedje leggen dat jullie straks in jullie productieomgeving ook gewoon alle ssh credentials in plaintext in de database hebben staan? It's an accident waiting to happen.

"Assumption is the mother of all fuckups."

Bewijst wederom dat je uberhaupt niet mijn posts leest en enkel je reactie neerkwakt.. in het begin van de thread hebben wij duidelijk aangegeven dat het momenteel om een dev omgeving gaat. Lijkt me logisch dat daar nog aan ontwikkeld word?

Daarbij, credentials is niet het enige vlak waarop fouten kunnen optreden. Ik begrijp dat de Nagios oplossing gebruik maakt van een client/server model. De uitbreidingen worden dan verzorgt door plugin modules beheerbaar vanuit een webinterface. Ook hier heb je te maken met beveiligingsrisicos als buffer overflows op de remote client.. een korte zoekactie op google toont ook aan dat dit eerder voorgekomen is. Dit is ook vaak een nadeel met bestaande populaire/opensource applicaties, ze zijn een populair doelwit van hackers/kwaadwillige. Natuurlijk zijn er ook weer de voordelen van een actieve community en gedeelde kennis bij gebonden. (ik wil de thread niet de kant uitduwen van pro/con OpenSource.. ik ben zelf absoluut voor openSource ontwikkeling).

Simpelweg je reactie neerkwakken en ervan uitgaan dat wij dezelfde fouten zullen maken als blijkbaar "in jou praktijk gebleken is" stel ik niet op prijs. Ik verzoek je dan ook het topic met rust te laten als je van de orginele vraag af blijft wijken.

EDIT:
Blijkbaar was het nodig om de post drastisch te editen waardoor bovenstaand mogelijk wat gedateerd is:
Ik begrijp niet in hoeverre jij het complex vind om op laag niveau heel simpel service statussen op te vragen en dit te returnen. Wij zijn niet meer geinteresseerd in uitgebreidde logs, trends, verbruik en wat er dan ook mocht gebeuren op die server als enkel de returnwaarde van /etc/init.d/[service] status....

Daarbij heb je wederom een antwoord klaar en probeer je me af te schrijven op mijn woordkeuze.. Ik begin een beetje moe te worden van je muggenzifterij en hatelijke reacties. Je verwijt mij "assumpties te maken" en het stopwoord van de thread "NIH" te hanteren terwijl je zelf de grootste assumpties maakt over onze werkwijze. Bij een simpele taak als dit gaat men niet volledige testimplementaties opzetten om 'even' te controleren of een applicatie gekoppeld kan worden aan onze eis. Het probleem met nagios is dan ook dat er een custom applicatie geschreven moet worden die een statuswaarde aan Nagios returned.. deze applicatie zal dan dus weer op iedere server aanwezig moeten zijn om deze waarde te kunnen returnen, hetgeen de beheerbaarheid van deze steeds lastiger maakt.
Mogelijk werk je zelf als nummer bij een grote R&D afdeling waar je weken/maanden de tijd krijgt om iets uit te zoeken, in dit geval ben je gezegend.. dit is echter niet overal zo.

[ Voor 27% gewijzigd door Verwijderd op 18-06-2009 11:05 ]

[Confusion]

Verwijderd schreef op donderdag 18 juni 2009 @ 10:56:
Bewijst wederom dat je uberhaupt niet mijn posts leest en enkel je reactie neerkwakt.. in het begin van de thread hebben wij duidelijk aangegeven dat het momenteel om een dev omgeving gaat. Lijkt me logisch dat daar nog aan ontwikkeld word?

Je hebt het woord 'straks' in mijn reactie gemist.

[..] ervan uitgaan dat wij dezelfde fouten zullen maken als blijkbaar "in jouw praktijk [..]

In mijn praktijk en die van mensen met decenniaIange ontwikkelingservaring die boeken schrijven met als onderwerp 'Hoe goed software te ontwikkelen'.

[phobosdeimos]

The right tool for the job.
PHP bestaat om eenvoudige web applicatie frontends te maken.
PHP is, in dit geval, niet the right tool for the job.
Schrijf gewoon een eenvoudige plugin voor Nagios of Zabbix.
10 regels code, en 100 keer beter dan wat jij met PHP kunt.

[RobIII]

Zullen we de discussie zelf devven/uitbesteden sowieso maar laten liggen? We zitten hier in PRG en daar devven we lekker zelf Of dat terecht is is een tweede en al een station eerder gepasseerd als je in PRG terecht komt

[Verwijderd]

Confusion schreef op donderdag 18 juni 2009 @ 11:03:
[...]

Je hebt het woord 'straks' in mijn reactie gemist.


[...]

In mijn praktijk en die van mensen met decenniaIange ontwikkelingservaring die boeken schrijven met als onderwerp 'Hoe goed software te ontwikkelen'.

Ah, dus omdat het "geschreven staat" staat het absoluut vast dat wij "HOOGST WAARSCHIJNLIJK" een slecht ontwikkelingstraject aflopen. Gelieve je reacties simpelweg achterwege te laten Confusion, ik stel je gespeculeer en assumpties niet op prijs.

[Verwijderd]

RobIII schreef op donderdag 18 juni 2009 @ 11:06:
Zullen we de discussie zelf devven/uitbesteden sowieso maar laten liggen? We zitten hier in PRG en daar devven we lekker zelf Of dat terecht is is een tweede en al een station eerder gepasseerd als je in PRG terecht komt

Amen, ik ben ervoor

[Confusion]

Verwijderd schreef op donderdag 18 juni 2009 @ 11:07:
[..] een slecht ontwikkelingstraject [..]

Ik doe geen uitspraken over de kwaliteit van jullie ontwikkelingstraject: ik informeer alleen over gedocumenteerde feiten uit het gemiddelde ontwikkelingstraject over de afgelopen tientallen jaren. Sorry als ik onterecht aanneem dat je gemiddeld bent.

Wat betreft je edit: de beheersbaarheid van een nagios client + script is niet lastiger dan die van een /etc/init.d/$service script, dat ook op alle servers moet staan, gesynched moet zijn met de laatste versie, etc. De complexiteit van de huidige oplossing (=ontopic) is wat dat betreft precies even groot.

Wat betreft ontopic: zie mijn gewijzigde eerdere reactie:

Volkomen ontopic: je probleem is een bug in de PHP SSH library. Wat in vredesnaam wil je verder van ons horen?

P.S. Ik heb geen gevoelens over jouw, je collega, jullie software, jullie oplossing of jullie ontwikkelingsproces. Er is niets hatelijk bedoeld; hooguit waarschuwend en onbegrip uitstralend.

[ Voor 13% gewijzigd door Confusion op 18-06-2009 11:23 ]

[Verwijderd]

Confusion schreef op donderdag 18 juni 2009 @ 11:15:
[...]

Ik doe geen uitspraken over de kwaliteit van jullie ontwikkelingstraject: ik informeer alleen over gedocumenteerde feiten uit het gemiddelde ontwikkelingstraject over de afgelopen tientallen jaren. Sorry als ik onterecht aanneem dat je gemiddeld bent.

Wat betreft je edit: de beheersbaarheid van een nagios client + script is niet lastiger dan die van een /etc/init.d/$service script, dat ook op alle servers moet staan, gesynched moet zijn met de laatste versie, etc. De complexiteit van de huidige oplossing (=ontopic) is wat dat betreft precies even groot.

Wat betreft ontopic: zie mijn gewijzigde eerdere reactie:

[...]

Jij mag het laatste woord hebben, ik ga verder niet in op Nagios reacties zoals je collega al aanraadde. Zeker niet met iemand die tientallen jaren ontwikkel ervaring heeft

OnTopic:
Een van de zaken waar het topic om gestart was om alternatieve opties te vinden om binnen PHP een ssh verbinding tot stand te brengen, of op een hele andere manier in PHP de status uit te lezen. Sommige gaven al aan om socket verbindingen te openen of SNMP te proberen.. dat zijn reacties waar we wat aan gehad hebben, deze opties worden zeker bekeken De bug in SSH2 module is de aanleiding, wij zoeken een oplossing.. en dát is waarvoor ik hier de thread startte met mijn collega

[ Voor 3% gewijzigd door Verwijderd op 18-06-2009 11:22 ]

[B0rf]

Een andere manier van 'multithreaden' die ik kan bedenken is door middel van shell executie. Op die manier kun je 1 cronjob aanmaken die dan verschillende nieuwe php-scripts start (of hetzelfde script met verschillende parameters). Zo kun je onder linux met php (neem aan dat de server die de services controleert ook een linuxmachine is aangezien de clients dat zijn) door een & achter een commando te zetten een process op de achtergond opstarten. Zo staat er in de PHP documentatie comments ook een leuke klasse om dit te regelen, waarbij je ook in het 'hoofdscript' kan controleren welke processen er nog lopen (http://php.net/function.exec#88704). Als de pcntl functies niet in PHP zijn gecompileerd is dit een mogelijke oplossing

edit
Je kunt ook met het 'ssh' commando onder linux remote commando's uitvoeren. Je moet er alleen wel voor zorgen dat je dan met zo min mogelijk nieuwe verbindingen openmaakt, dus in 1 keer zo veel mogelijk uitvoeren. Door commando's achter elkaar te zetten met ; ertussen kunnen meerdere commando's in 1 keer uitgevoerd worden, de uitvoer komt dan alleen wel in 1 keer terug, en je hebt de tussentijdse returnwaardes ook niet meer

[ Voor 21% gewijzigd door B0rf op 18-06-2009 11:32 ]

[Verwijderd]

B0rf schreef op donderdag 18 juni 2009 @ 11:22:
Een andere manier van 'multithreaden' die ik kan bedenken is door middel van shell executie. Op die manier kun je 1 cronjob aanmaken die dan verschillende nieuwe php-scripts start (of hetzelfde script met verschillende parameters). Zo kun je onder linux met php (neem aan dat de server die de services controleert ook een linuxmachine is aangezien de clients dat zijn) door een & achter een commando te zetten een process op de achtergond opstarten. Zo staat er in de PHP documentatie comments ook een leuke klasse om dit te regelen, waarbij je ook in het 'hoofdscript' kan controleren welke processen er nog lopen (http://php.net/function.exec#88704). Als de pcntl functies niet in PHP zijn gecompileerd is dit een mogelijke oplossing

Thanks, klinkt als een goede oplossing en gaan we tevens bekijken

[Confusion]

Verwijderd schreef op donderdag 18 juni 2009 @ 11:21:
Sommige gaven al aan om socket verbindingen te openen of SNMP te proberen.. dat zijn reacties waar we wat aan gehad hebben, deze opties worden zeker bekeken

Dan heb je sowieso client software op iedere machine nodig, die op de betreffende socket luistert en SNMP antwoordt.

* Confusion twijfelt lang, maar zegt het toch:
Het lijkt me een goed idee om het werkingsprincipe van bestaande monitoring oplossingen in ieder geval nog eens goed te bestuderen, want dat zou je direct op het idee van het gebruik van sockets en SNMP gebracht hebben. Waarschijnlijk krijg je er nog wel meer goede ideeen van.

Overigens, multithreading oplossingen vind ik geen goed advies. Je hebt geen performance probleem, maar een library probleem. Daar omheen gaan werken met behulp van multithreading introduceert onnodige extra complexiteit. Concurrency bugs zijn naar en moeilijk te vinden. Dan zou ik eerder proberen zelf die bug in die library te fixen.

[ Voor 19% gewijzigd door Confusion op 18-06-2009 11:39 ]

[B0rf]

Het probleem is dat de servers lastig sequentieel te controleren zijn. Daarnaast is het controleren niet echt zo'n zware taak dat 't elkaar in de weg zit als je het parallel doet. Ik ben het met je eens dat alleen multithreading hier de boel niet gaat oplossen, stel dat het 100 servers worden dan kun je niet opeens 100 nieuwe processen gaan maken, maar moet je de boel inderdaad slimmer gaan aanpakken, maar alles sequentieel is waarschijnlijk ook niet erg handig. Je zou bijvoorbeeld ook een 2-stappen methode kunnen doen. Eerst probeer je (een gedeelte van) de services te controleren door een socketverbinding te maken naar de poort(en) waar deze op luistert, en hierna de overige services via een ssh-verbinding. Het voordeel van het controleren via een socketverbinding is ook dat je (met kennis van het protocol van de service), ook kunt kijken of een service ook echt werkt. Zo zou je van een ftp- of http-service kunnen proberen een bepaald bestand te downloaden. Dit kun je niet controleren via SSH door te kijken of een bepaald process nog draait.

[Confusion]

B0rf schreef op donderdag 18 juni 2009 @ 11:52:
Ik ben het met je eens dat alleen multithreading hier de boel niet gaat oplossen, stel dat het 100 servers worden dan kun je niet opeens 100 nieuwe processen gaan maken,

100 processen die maar kort leven en het grootste deel van de op I/O staan te wachten moet zelfs voor een 10 jaar oude machine geen probleem zijn (zolang je zorgt dat ze niet gaan swappen). Eventueel kan je het aantal processen limiteren en met een producer/consumer model werken om ze aan de gang te houden. Daar zijn vast ook al wel libs voor in PHP. Wat dat betreft moet het goed te doen zijn.

[_JGC_]

Ik heb hier een nagios server die elke minuut controleert op 22 hosts en 89 services. De server zelf is een single Pentium 3 1.13GHz met 1.5GB geheugen. Uit de statistieken van Nagios haal ik dat dit nog gewoon zonder belangrijke vertragingen werkt (snelste check is 0.02s, traagste check is 4 seconden, gemiddeld 1.2 seconden over alle services). Er wordt hier gewerkt met socket connecties naar diverse services, SNMP voor dingen als diskruimte en NRPE voor dingen als het aantal mails in de mailqueue.
MySQL wordt hier gecontroleerd met een testaccount zonder rechten, HTTP wordt gewoon gecontroleerd met zowel een JSP als een PHP scriptje en SNMP gaat gewoon via een community string die alleen vanaf de nagios server werkt. Verder gaan alle checks over een VPN, dus security is geen probleem. Voor dingen die we niet via SNMP of remote sockets kunnen testen gebruiken we dus NRPE, waar je in jouw geval alsnog SSH voor kunt gebruiken (ik neem aan dat je een low-privilege account met SSH keys gebruikt daarvoor?).

[phobosdeimos]

_JGC_ schreef op donderdag 18 juni 2009 @ 13:21:
Voor dingen die we niet via SNMP of remote sockets kunnen testen gebruiken we dus NRPE, waar je in jouw geval alsnog SSH voor kunt gebruiken (ik neem aan dat je een low-privilege account met SSH keys gebruikt daarvoor?).

Helaas pindakaas, TS gebruikt gewoon root account, zonder keys, en met de paswoorden plaintext in een mysql database...
Dat strookt helemaal met de PHP mentaliteit, idd.

[Verwijderd]

phobosdeimos schreef op donderdag 18 juni 2009 @ 13:43:
[...]


Helaas pindakaas, TS gebruikt gewoon root account, zonder keys, en met de paswoorden plaintext in een mysql database...
Dat strookt helemaal met de PHP mentaliteit, idd.

Moet ik hier nu echt serieus op ingaan? Wat een kansloze reactie. Als je niet anders dan speculaties toe te voegen hebt aan dit topic, reageer dan gewoon niet.

[ Voor 11% gewijzigd door Verwijderd op 18-06-2009 14:09 ]

[LMD]

Verwijderd schreef op donderdag 18 juni 2009 @ 14:07:
[...]


Moet ik hier nu echt serieus op ingaan? Wat een kansloze reactie. Als je niet anders dan speculaties toe te voegen hebt aan dit topic, reageer dan gewoon niet.

Na het lezen van het topic, kom je in de wat latere reacties wat verbitterd over. Maar zelfs in Ontwikkeling omgeving zou je zoiets gelijk goed moeten inrichten, bespaart je tijd en energie om dit alsnog te moeten doen.

Zelf volg ik niet helemaal de keuze om elke 10 minuten te pollen. Als beheer loop je dan standaard bij problemen 10 minuten achter voor je op de hoogte bent. In php is veel mogelijk, maar de vraag is of dit de efficiënte manier is om de problemen van je libery te omzeilen.

[Verwijderd]

LMD schreef op donderdag 18 juni 2009 @ 14:19:
[...]


Na het lezen van het topic, kom je in de wat latere reacties wat verbitterd over.

Dat zal best. Ik vind het gewoon altijd zo jammer hoe topics op tweakers.net lopen: je stelt een vraag en het enige wat besproken wordt zijn je motieven. De toon waarop sommige mede tweakers antwoorden is op z'n zachts gezegd irritant te noemen: het lijkt wel of men op hun pik getrapt is als er niet voor oplossing X gekozen wordt.

Ook word er op dit forum standaard vanuit gegaan dat je, net zoals álle andere php ontwikkelaars, een prutser bent die geen rekening houd met beveiliging etc (zie ook mijn andere topics). Wij 'stroken' kenbaar de php mentaliteit. Want ja, iedereen die gebruik maakt van php weet niet waar die mee bezig is. Waarom altijd dat geflame richting PHP, of mensen die het gebruiken?

Ik stel een vraag en er wordt mee gedacht over eventuele andere tooltjes die hetzelfde kunnen bereiken. Dan geven ik en mijn collega voldoende motieven waarom we daar niet voor gekozen hebben. Maar goed, hier gaan we uiteraard spijt van krijgen, want mensen met tientallen jaren ervaring hebben het allemaal anders zien lopen. Het staat zelfs in de boeken.

Nogmaals: ik waardeer dat er mee gedacht word, maar het toontje waarop is gewoon zo ontzettend vervelend bij sommige mensen. Maar goed, dat is nou eenmaal bekend in de IT wereld.

[Tead]

Grijze Vos schreef op donderdag 18 juni 2009 @ 09:19:
[...]

En hoeveel seconden gaan er in 10 minuten? Niet echt een zinnige oplossing als ze elke 10 minuten willen pollen.

De TS geeft aan dat hij nu aan 300 seconde meestal genoeg heeft maar soms fout gaat. Gemiddeld zal een request dan ong. 4 seconde duren. Je geeft een request op deze manier juist een kortere time-out.

Wat je nog aan het script zou kunnen toevoegen is een running file. Wat ik in mijn script had dat hij in de constructor de time() in een $file schreef. In de destructor werd deze weer op 0 gezet. Ook werd in de constructor bekeken of er een tijd is gezet en hoelang geleden dat was. Is hij 0 dan deed hij zijn ding, was er een tijd boven de (bijvoorbeeld) 30 minuten deed hij dat ook. Was er een tijd binnen 30 minuten stopte het script. Op deze manier kan je dus elke minuut gaan pollen. Als het script al bezig is laat hij het script met rust.

[Creepy]

Verwijderd schreef op donderdag 18 juni 2009 @ 14:07:
[...]


Moet ik hier nu echt serieus op ingaan? Wat een kansloze reactie. Als je niet anders dan speculaties toe te voegen hebt aan dit topic, reageer dan gewoon niet.

Dit wil ik wel even benadrukken. Reageer dan inderdaad gewoon niet.

[Wolfboy]

Verwijderd schreef op donderdag 18 juni 2009 @ 14:28:
Dat zal best. Ik vind het gewoon altijd zo jammer hoe topics op tweakers.net lopen: je stelt een vraag en het enige wat besproken wordt zijn je motieven. De toon waarop sommige mede tweakers antwoorden is op z'n zachts gezegd irritant te noemen: het lijkt wel of men op hun pik getrapt is als er niet voor oplossing X gekozen wordt.

Dat is natuurlijk een flinke generalisatie, we proberen je gewoon een zo goed mogelijke oplossing te bieden. Je kan vrij veel met PHP maar het is niet per definitie de oplossing voor elk probleem. Je moet je dus ook altijd afvragen of het wel de "right tool for the job" is.

Door het gebrek aan ingebouwde multithreading is PHP m.i. per definitie niet geschikt voor dergelijke klusjes. Hier is wel omheen te hacken, maar je moet jezelf toch de vraag stellen wat de beste optie is op de langere termijn. Als het met 15 servers al niet goed gaat, wat voor hackwerk ga je dan nodig hebben om het voor 100 servers werkend te gaan krijgen? Nu kan je die afweging nog makkelijk maken, straks niet meer.

Ook word er op dit forum standaard vanuit gegaan dat je, net zoals álle andere php ontwikkelaars, een prutser bent die geen rekening houd met beveiliging etc (zie ook mijn andere topics). Wij 'stroken' kenbaar de php mentaliteit. Want ja, iedereen die gebruik maakt van php weet niet waar die mee bezig is. Waarom altijd dat geflame richting PHP, of mensen die het gebruiken?

JE maakt een prima punt, al geeft plaintext wachtwoorden in de database mij ook geen geweldig gevoel eigenlijk. Is het zo vreemd dat als je voor die oplossing kiest dat mensen er dan vanuit gaan dat de rest van het systeem ook niet veilig is?

Ik stel een vraag en er wordt mee gedacht over eventuele andere tooltjes die hetzelfde kunnen bereiken. Dan geven ik en mijn collega voldoende motieven waarom we daar niet voor gekozen hebben. Maar goed, hier gaan we uiteraard spijt van krijgen, want mensen met tientallen jaren ervaring hebben het allemaal anders zien lopen. Het staat zelfs in de boeken.

Nogmaals: ik waardeer dat er mee gedacht word, maar het toontje waarop is gewoon zo ontzettend vervelend bij sommige mensen. Maar goed, dat is nou eenmaal bekend in de IT wereld.

Het blijven allemaal adviezen uiteraard, je hoeft ze niet op te volgen maar als je dan in de problemen komt moet je je toch afvragen of je keuze wel de juiste was.

Vergeet in ieder geval niet dat veel IT'ers last hebben van het N.I.H. (not invented here) syndroom
Iedereen heeft gewoon (het recht op) zijn eigen mening.

[Confusion]

Verwijderd schreef op donderdag 18 juni 2009 @ 14:28:
Ook word er op dit forum standaard vanuit gegaan dat je, net zoals álle andere php ontwikkelaars, een prutser bent [..]

Sorry hoor, maar als je een monitoring oplossing aan het schrijven bent en anderen brengen je met woorden als 'sockets' en SNMP op ideeen, dan ben je aan het prutsen.

[DiedX]

Aan Jesper en Collega,

Veel gesproken en gezegd. Ik ga niet op alles in, ik ben het met veel van collegae-tweakers eens.

Doe mij en jezelf een lol:

* mocht je gebruik willen maken van SSH, gebruik dan Public keys. Scheelt je een root-wachtwoord opslaan. ssh-keygen is je vriend (man ssh-keygen);
* Mocht je de mogelijkheid hebben, maak dan gebruik van een niet-root gebruiker.
* Zabbix heeft de mogelijkheid om als niet-ingelogde gebruiker data te tonen. Die data kunnen jullie (ongetwijfeld via een iframe of netjes via cURL/$oplossing) netjes in je frontend tonen. Zabbix kan, net zoals nagios en al die andere pakketten custom-scripts aanroepen, precies datgene wat je nu aan het programmeren bent. Het scheelt je een bek werk

[Wolfboy]

DiedX schreef op donderdag 18 juni 2009 @ 23:22:
* Mocht je de mogelijkheid hebben, maak dan gebruik van een niet-root gebruiker.

FTFY

Maak eventueel een los programma die met sudo/suid als root gedraait kan worden. Een automatisch script als root laten inloggen is _altijd_ een slecht idee.

Bij alle servers die ik beheer staat remote root login dan ook gewoon uit, als je root wil worden zal je eerst een gewone gebruikers account moeten hebben om in te loggen. Als je dan in de wheel groep zit en je weet het root wachtwoord dan kan je inloggen als root. Minder dan dat mag imho niet voorkomen op servers.

[Verwijderd]

Sorry hoor, maar als je een monitoring oplossing aan het schrijven bent en anderen brengen je met woorden als 'sockets' en SNMP op ideeen, dan ben je aan het prutsen.

Ah, juist. Dus puur omdat ik geen ervaring met sockets of SNMP heb en even uit wilde zoeken wat diegene ermee bedoelde, ben ik aan het prutsen. Oké. De volgende keer als er een term voorbij komt waar ik weinig tot niets mee gedaan heb zal ik je eerst even om advies komen vragen.

[Verwijderd]

Confusion schreef op donderdag 18 juni 2009 @ 22:58:
[...]

Sorry hoor, maar als je een monitoring oplossing aan het schrijven bent en anderen brengen je met woorden als 'sockets' en SNMP op ideeen, dan ben je aan het prutsen.

Gelieve reacties achterwege te laten Confusion, je hebt in de afgelopen 5 posts nog geen enkel zinnig bericht geplaatst. Wederom ga je totaal off-topic en zit je deze thread enkel maar wat the trollen, heb je nou werkelijk niets beters te doen? Een superieure software ontwikkelaar als jij zou zijn handen toch vol moeten hebben aan werk en wereldverbetering, niet?

DiedX schreef op donderdag 18 juni 2009 @ 23:22:
Doe mij en jezelf een lol:

* mocht je gebruik willen maken van SSH, gebruik dan Public keys. Scheelt je een root-wachtwoord opslaan. ssh-keygen is je vriend (man ssh-keygen);
* Mocht je de mogelijkheid hebben, maak dan gebruik van een niet-root gebruiker.
* Zabbix heeft de mogelijkheid om als niet-ingelogde gebruiker data te tonen. Die data kunnen jullie (ongetwijfeld via een iframe of netjes via cURL/$oplossing) netjes in je frontend tonen. Zabbix kan, net zoals nagios en al die andere pakketten custom-scripts aanroepen, precies datgene wat je nu aan het programmeren bent. Het scheelt je een bek werk

Hier zijn we van op de hoogte, overigens is het niet zo dat ik niet weet hoe je public keys gebruikt, we doen niet anders in de datacommunicatie tussen deze servers.

[ Voor 40% gewijzigd door Verwijderd op 19-06-2009 08:32 ]

[Gerco]

Verwijderd schreef op vrijdag 19 juni 2009 @ 08:20:
Ah, juist. Dus puur omdat ik geen ervaring met sockets of SNMP heb en even uit wilde zoeken wat diegene ermee bedoelde, ben ik aan het prutsen. Oké. De volgende keer als er een term voorbij komt waar ik weinig tot niets mee gedaan heb zal ik je eerst even om advies komen vragen.

Ik denk dat Confusion bedoelde dat je, wanneer je ook maar iets met monitoring zoekt op Google, je als eerste links over pakketten voor SNMP en remote socket monitoring tegen gaat komen.

Socket connecties maken en SNMP zijn zo ongeveer de default manier om alles te monitoren (van servers tot switches en printers). In ieder geval de eerste dingen die geprobeerd worden alvorens verder te kijken. Als je dus een monitoring pakket aan het programmeren bent is het redelijk vanzelfsprekend dat je van deze termen op de hoogte bent, het staat immers prominent in de feature list van zowat alle te evalueren software.

[ Voor 7% gewijzigd door Gerco op 19-06-2009 08:57 ]

[Verwijderd]

Gerco schreef op vrijdag 19 juni 2009 @ 08:55:
[...]

Ik denk dat Confusion bedoelde dat je, wanneer je ook maar iets met monitoring zoekt op Google, je als eerste links over pakketten voor SNMP en remote socket monitoring tegen gaat komen.

Socket connecties maken en SNMP zijn zo ongeveer de default manier om alles te monitoren (van servers tot switches en printers). In ieder geval de eerste dingen die geprobeerd worden alvorens verder te kijken. Als je dus een monitoring pakket aan het programmeren bent is het redelijk vanzelfsprekend dat je van deze termen op de hoogte bent, het staat immers prominent in de feature list van zowat alle te evalueren software.

Dat maakt het nog steeds geen constructieve post, overigens zijn wij nooit op zoek gegaan naar softwarepakketten om dit op te lossen voor ons. De thread is gestart om simpelweg de vraag te beantwoorden "hoe maken we ssh2 sneller in php", niet meer/niet minder. Helaas vonden sommige het nodig om de thread te hijacken en er een zelfbouw/premade discussie van te maken.

[Janoz]

Verwijderd schreef op vrijdag 19 juni 2009 @ 09:19:
De thread is gestart om simpelweg de vraag te beantwoorden "hoe maken we ssh2 sneller in php", niet meer/niet minder.

http://weblogs.asp.net/al...ve/2005/05/25/408925.aspx

[CrankyGamerOG]

Verwijderd schreef op woensdag 17 juni 2009 @ 13:02:
Binnen ons CRM heb ik met een collega een module gemaakt die de statussen van onze servers checkt. Wij zijn een kleine ICT dienstverlener met o.a. voip diensten, dus het is vrij cruciaal dat wij snel op de hoogte zijn als er een server down is.

De module werkt als volgt. Elke server heeft een aantal services (het gaat hier om alleen Linux servers), zoals bijvoorbeeld mysqld, httpd, asterisk, hylafax, etc.....

Er draait elke 10 minuten een cronjob die via SSH2 inlogt op al deze servers.

Deze cronjob doet het volgende:

• Hij vraagt de gegevens van al onze servers op (ip, port, username, password, alias, etc), die in een mysql tabel staan
• Vervolgens word er verbinding gemaakt via SSH2
• Vervolgens worden alle services opgevraagd die bij deze server horen
• Het commando /etc/init.d/$service status wordt uitgevoerd, aan de hand van de return waarde wordt de database geupdate
• Per service die niet (meer) draait, zal er een SMS gestuurd worden. De tabel wordt geupdate zodat we niet elke keer als de cronjob draait weer een SMS zullen ontvangen, anders worden we dood gespamt (cron draait elke 10 min)

Al met al een flinke klus, aangezien we op dit moment 15+ servers hebben met elk gemiddeld 5 services.

Het probleem. Ik heb max_execution_time op 300 staan , en nog exceed hij dit af en toe (dus niet elke keer).

Wat kan ik hier nou aan doen? Simpelweg max_execution_time nog hoger zetten? Het is een dedicated server voor ons CRM systeem, dus in principe zou dit geen kwaad moeten kunnen? Is er wellicht nog een andere manier om de performance van dit script te optimaliseren?

Alvast bedankt voor het meedenken.

Waarom doe je zo moeilijk ? er bestaat een uitermate geschikt programma voor dit soort taken, zonder dat je zelf hoeft te rommelen , nagios !

En dan icm met cacti kun je heel veel bereiken kwa statistieken en waarschuwingen mbt tot services.
(Ik krijg bijv een sms als er een service niet bereikbaar is )

[Verwijderd]

Janoz schreef op vrijdag 19 juni 2009 @ 09:21:
[...]

http://weblogs.asp.net/al...ve/2005/05/25/408925.aspx

We gebruiken deze module ook in andere applicaties, het antwoord op de vraag blijft ongeacht de toepassing dus interessant voor ons en mogelijk andere op dit forum.

@Def!ance:
Wat jij "moeilijk" noemt is ongeveer 2 uurtjes werk in ons framework, aanzienlijk minder dan een volledige Nagios implementatie. Daarbij moeten we ook bij Nagios nog aardig wat rommelen met applicaties die statussen returnen van zeer specifieke hardware.

[Confusion]

Verwijderd schreef op vrijdag 19 juni 2009 @ 08:20:
Ah, juist. Dus puur omdat ik geen ervaring met sockets of SNMP heb en even uit wilde zoeken wat diegene ermee bedoelde, ben ik aan het prutsen.

Nee, omdat je je niet gerealiseerd hebt dat je een probleem aan het oplossen was dat vele mensen voor je al een keer opgelost hebben, dat je je niet hebt afgevraagd wat volgens anderen de beste oplossing was en niet hebt uitgezocht tegen welke problemen zij aanliepen. Omdat jullie denken te speciaal te zijn voor de adviezen die overal te vinden zijn en hier gegeven worden. Omdat je een root wachtwoord in plaintext in een database zet.

Om de houding:

Verwijderd schreef op woensdag 17 juni 2009 @ 15:52:
Als iedereen voor die methode blijft kiezen zullen er nooit betere oplossingen op de markt komen Daarbij hebben wij te maken met té specifieke services en interne appliacties om te laten controleren door één generiek softwarepakket.

waardoor iemand anders straks met een halfgare zelf bij elkaar geharkte monitoring oplossing zit. Server monitoring is een onderdeel van het serverbeheer en hoort compleet los te staan van een CRM. Hooguit zorg je dat de informatie van de monitoring ook voor het CRM beschikbaar is, zodat je het kan weergeven. Iets totaal ongerelateerds als monitoring onderdeel van de code van een CRM maken is al een fuckup by itself.

Verwijderd schreef op vrijdag 19 juni 2009 @ 08:28:
totaal off-topic [..] wereldverbetering

Mensen gaan hier offtopic in een poging de wereld een beetje beter te maken, door jullie dingen te leren. Een root wachtwoord in een database is een big fucking nono. 'Het is maar een development machine': famous last words. Als iemand die hijacked, dan kan hij alles op je interne netwerk zien. Als je een keer op een andere machine inlogged vanaf die bak, dan heeft zijn keystrokelogger dat wachtwoord ook. Ik mag hopen dat er bij jullie geen creditcard nummers over het interne netwerk gaan, anders kan je je PCI compliancy audit wel schudden de volgende keer. Als wij allemaal zo dom en ongeinformeerd zijn, leer ons dan eens wat, in plaats van ons gewoon tegen te blijven spreken.

Je zet nooit, nooi, nooi, zelfs niet als grap, een bedrijfsmatig root wachtwoord in plaintext ergens neer. Dat is grond voor ontslag.

Als mensen je onderbouwd vertellen: "je stelt de verkeerde vraag", dan kan je nog 100x blijven roepen dat je het over je eigen oorspronkelijke vraag wilt hebben: we beschermen je tegen jezelf door je daar geen antwoord op te geven. Je stelt de verkeerde vraag. Als dat niet zo is, maak dan maar eens aannemelijk waarom dat niet zo is. Voorlopig trekken 9 van de 10 mensen hier uit de gegevens die je hebt verschaft de conclusie dat monitoring software waarschijnlijk wel de beste oplossing is.
(Edit: Oh spuit 11, de link van Janoz beschreef dat al)

[ Voor 19% gewijzigd door Confusion op 19-06-2009 10:38 ]

[Verwijderd]

Confusion schreef op vrijdag 19 juni 2009 @ 10:13:
[...]

Nee, omdat je je niet gerealiseerd hebt dat je een probleem aan het oplossen was dat vele mensen voor je al een keer opgelost hebt, dat je je niet hebt afgevraagd wat volgens hen de beste oplossing was en niet hebt uitgezocht tegen welke problemen zij aanliepen. Omdat jullie denken te speciaal te zijn voor de adviezen die overal te vinden zijn en hier gegeven worden.


[...]

Mensen gaan hier offtopic in een poging de wereld een beetje beter te maken, door jullie dingen te leren. Een root wachtwoord in een database is een big fucking nono. 'Het is maar een development machine': famous last words. Als iemand die hijacked, dan kan hij alles op je interne netwerk zien. Als je een keer op een andere machine inlogged vanaf die bak, dan heeft zijn keystrokelogger dat wachtwoord ook. Ik mag hopen dat er bij jullie geen creditcard nummers over het interne netwerk gaan, anders kan je je PCI compliancy audit wel schudden de volgende keer.

Je zet nooit, nooi, nooi, zelfs niet als grap, een bedrijfsmatig root wachtwoord in plaintext ergens neer. Dat is grond voor ontslag.

Als mensen je onderbouwd vertellen: "je stelt de verkeerde vraag", dan kan je nog 100x blijven roepen dat je het over je eigen oorspronkelijke vraag wilt hebben: we beschermen je tegen jezelf door je daar geen antwoord op te geven. Je stelt de verkeerde vraag. Als dat niet zo is, maak dan maar eens aannemelijk waarom dat niet zo is. Voorlopig trekken 9 van de 10 mensen hier uit de gegevens die je hebt verschaft de conclusie dat monitoring software waarschijnlijk wel de beste oplossing is.

Ik heb meer het idee dat je geen flauw idee hebt hoe je onze oorspronkelijke vraag kan beantwoorden en daarom slechts je enige antwoord door wilt duwen. Tevens kom je wederom met vage, ongebaseerde assumpties over creditcardnummers en allerlij irrelevante zaken. Daarbij begin ik je one-liners ook een beetje zat te raken. Ik heb je nu al een keer of drie/vier verzocht deze thread simpelweg met rust te laten aangezien je het niet kan laten om off-topic door te blijven zeuren over je, schijnbaar, superieure kennis en kennis van zaken. Tevens ga je er weer blind vanuit dat wij de applicatie testen op live servers.. denk je nou werkelijk dat wij deze applicatie testen op productieservers? De monitor applicatie logt in op virtuele servers speciaal ingericht voor dit doel.

Aangezien we op de rit zitten met one-liners besluit ik er ook maar eens één in de gooien:

“In a room full of top software designers, if two agree on the same thing, that’s a majority.”
– Bill Curtis

[Confusion]

Verwijderd schreef op vrijdag 19 juni 2009 @ 10:36:
Tevens ga je er weer blind vanuit dat wij de applicatie testen op live servers.. denk je nou werkelijk dat wij deze applicatie testen op productieservers?

Nee, ik denk dat je niet kan lezen, want ik heb niets van dien aard geschreven.

[ Voor 6% gewijzigd door Confusion op 19-06-2009 10:40 ]

[Verwijderd]

Confusion schreef op vrijdag 19 juni 2009 @ 10:40:
[...]

Nee, ik denk dat je niet kan lezen, want ik heb niets van dien aard geschreven.

Wederom een loze opmerking die totaal niets toevoegd.

Je zet nooit, nooi, nooi, zelfs niet als grap, een bedrijfsmatig root wachtwoord in plaintext ergens neer. Dat is grond voor ontslag.

en root wachtwoord in een database is een big fucking nono. 'Het is maar een development machine': famous last words. Als iemand die hijacked, dan kan hij alles op je interne netwerk zien. Als je een keer op een andere machine inlogged vanaf die bak, dan heeft zijn keystrokelogger dat wachtwoord ook.

Er staan dus momenteel GEEN root wachtwoorden in de database waarmee we 'gehacked' kunnen worden of wat dan ook, al vind men op wonderbaarlijke manier een lek in onze dev server dan is er totaal niets aan de hand behalve dat ze de laatste checkout kunnen downloaden.. Kortom je reactie slaat werkelijk nergens op, zeker niet aangezien er veel, veel, veel eerder al aangegeven is dat onze huidige methode met plain-text DB niet toereikend is en we voor een live-versie zoiezo over zullen stappen op keys.

Edit:
Trouwens, wat houd jou nou vast aan dit topic? Waarom kan je het niet loslaten?

[ Voor 3% gewijzigd door Verwijderd op 19-06-2009 10:47 ]

[CrankyGamerOG]

en ik wil nog even toevoegen dat een ssh2 connectie opzetten dmv php ook niet echt slim is
as in : potential security risk.......

Je bent te koppig om de adviezen die men je hier geeft aan te nemen en op zn minst naar te gaan kijken.
Dan houd het voor mij ook verder op, waarom kom je om hulp vragen als de antwoorden je niet bevallen?
En daarbij een monitoringsysteem zoals die al 100x zijn uitgevonden, en ook 100en oplossingen bied voor jouw probleem is niet toereikend?

Een monitoringsysteem moet LOS staan van alle andere onderdelen in het bedrijf, status zien in je crm ok, maar het moet geen GEINTREGEERD onderdeel zijn van......

[Verwijderd]

CrankyGamerOG schreef op vrijdag 19 juni 2009 @ 10:54:
en ik wil nog even toevoegen dat een ssh2 connectie opzetten dmv php ook niet echt slim is
as in : potential security risk.......

Je bent te koppig om de adviezen die men je hier geeft aan te nemen en op zn minst naar te gaan kijken.
Dan houd het voor mij ook verder op, waarom kom je om hulp vragen als de antwoorden je niet bevallen?
En daarbij een monitoringsysteem zoals die al 100x zijn uitgevonden, en ook 100en oplossingen bied voor jouw probleem is niet toereikend?

Een monitoringsysteem moet LOS staan van alle andere onderdelen in het bedrijf, status zien in je crm ok, maar het moet geen GEINTREGEERD onderdeel zijn van......

De applicatie zelf is niet geïntegreerd, het is een losse applicatie.. het word enkel beheerd vanuit het CRM. Ik verzoek je dan ook om daadwerkelijk mijn reacties in deze thread te lezen. Ik geef meermaal (echt ontiggelijk vaak inmiddels) aan dat ik de suggesties wel in acht neem, daarbij is er nooit gevraagd "Beste tweakers, hoe kan ik dit ANDERS doen dan ik het momenteel aanpak". Er is enkel gevraagd "hoe maken we de SSH2 module sneller". Als je dat niet uit de voorgaande vier paginas op hebt kunnen maken dan vraag ik me af of je de thread uberhaupt doorgelezen hebt voordat je je antwoord hier plaatste.

en ik wil nog even toevoegen dat een ssh2 connectie opzetten dmv php ook niet echt slim is
as in : potential security risk.......

Als addendum op uwe toevoeging, het is prima te doen om een ssh2 verbinding op te zetten middels een chrooted gebruiker op het platform.

Overigens zijn nagios clients ook een 'potential security risk.....' op een server, er zijn toch al diverse exploits geweest in de vorm van buffer overflows op deze clients.

[ Voor 14% gewijzigd door Verwijderd op 19-06-2009 11:02 ]

[WiebeV]

Als je dit met PHP wil doen dan zou ik inderdaad proberen om meerdere SSH connecties tegelijk te openen.

Dit kan je natuurlijk op verschillende manieren doen:

Non blocking streams
Je zou (en dit lijkt mij opzich de beste manier) de SSH sockets op non-blocking kunnen zetten.
Hierdoor kan je meerdere sockets tegelijk openen, want ik neem aan dat dit het meeste tijd kost ?

Multithreaden
Child processes maken is mischien ook wel een idee (soort van Multithreading.. ).
Dit kan met de PCNTL library in PHP (werkt alleen op Unix)

Meerdere processen
Je kan ook voor elke server een apart process starten, maar dit lijkt mij niet zo efficient.

Een combo van de 1e oplossing + voor elke x aantal servers een apart process starten lijkt mij het best. (ligt er een beetje aan hoeveel servers je wil controleren)

[CrankyGamerOG]

Nee, want dat heb ik wel degelijk, maar ik ga jou niet helpen om een *inferieur product op te zetten in een kritieke omgeving(uiteindelijk) en dat jouw opvolger dan met de gebakken peren zit.
Als je kiest voor een product dat al door 1000en voor jou gedaan is, dan is voor jouw opvolger het ook allemaal makkelijker te repareren mocht het ooit stuk gaan.

inferieur is hier niet denegrerend bedoeld

Dat men niet de antwoorden geeft die jij wenst, komt omdat je zelf begint over monitoring en dergelijke, vraag dan gewoon ik wil een ssh2 connectie in php sneller maken, en dit is mijn probleem.

Omdat je je probleem zo volledig omschrijft roep je hier veel aandacht omdat er hier menig tweakers dagelijks in de weer zijn met serverparken waar je U tegen zegt.
(inclusief ondergetekende).

Als de ervaringen van zulks mensen jou niet interesseren, is dat idd jouw probleem, lees er dan langsaf, en reageer er dan niet op?
Je lokt de discussie telkens zelf uit.

Verwijderd schreef op vrijdag 19 juni 2009 @ 10:59:


Overigens zijn nagios clients ook een 'potential security risk.....' op een server, er zijn toch al diverse exploits geweest in de vorm van buffer overflows op deze clients.

Nu doe je het weer...
Maar ik ga er wel op in......

Ja, dit klopt maar dat was en is alleen een risk als je nagios als een kip zonder kop gebruikt.
Dergelijke software moet intern draaien wat niet van buitenaf bereikbaar is zonder een geauthoriseerd VPN .

[ Voor 21% gewijzigd door CrankyGamerOG op 19-06-2009 11:06 ]

[Creepy]

Hmmja... er is nu wel genoeg voer gezegd.

Tips om je daadwerkelijke vraag op te lossen (het sneller krijgen van het SSH2 gebeuren) heb je nu gehad dus doe er je voordeel mee

Hier wordt graag meegedacht met het probleem en als er hier mensen zijn die denken dat er voor je daadwerkelijke probleem (het checken van diensten/servers/hardware) betere oplossing bestaan dan worden die ook gemeld. Vind je dat helemaal niks? Dan spijt me dat maar dan is dat echt jammer voor je. GoT is geen helpdesk maar een discussie forum dus blijven hameren erop dat er mensen zijn die je daadwerkelijke vraag niet beantwoorden is niet nodig. Alle reacties worden gegeven om jou beter te helpen, je geeft zelf ook al aan naar sommige dingen niet gekeken te hebben. Soms is een andere oplossing een betere en daarom worden andere oplossingen ook gemeld. Het is aan jou om te bepalen of dat ook het geval is of niet. En dat wordt echt alleen maar gedaan om jou te helpen.

Anyway, er zijn wat mij betreft teveel (te) felle reacties heen en weer gegaan en het is wel tijd dat het gaat stoppen. Dus deze gaat nu dicht. Mocht je toch een nieuw topic willen openen bedenk dan wel dat er hier met je meegedacht worden en niet alleen simpel weg een antwoord op je directe vraag wordt gegeven. Wil je dat echt niet hebben dan is GoT waarschijnlijk niet het juiste forum