Program indítási furcsaság, a putty három példányban indul.

C/C++

Sziasztok!

Írogatok pár éve (lényegében magamnak) egy hálózat monitorozó/menedzselő/dokumentáló programot ( https://github.com/csikfer/lanview2 ). Ehhez legutóbb egy definiálható szerszámkészletet adtam, pl. a switch-re rájelentkezés CLI vagy Web (ami van). Egy (minimális) böngésző tab megnyitása viszonylag egyszerű volt Qt-ban, de a Terminál vagy SSH ablak megnyitására nem találtam megoldást (Qt környezet, lényeges a multiplatform Windows + Linux). Így maradt külső program hívása. Windows alatt a telnet vagy ssh-hoz a putty-ra esett a választás. Itt van egy olyan fura jelenség, hogy a putty (A QProcess::startDetached(...) -el indítva) három (néha kettő) példányban indul el. Ha szinkron indítom (várok a befejezésre), akkor csak egy példányban. Linux alatt nincs ilyen jelenség, és persze putty sem. Kipróbáltam más program hívását is, pl. a zenmap (nmap Windows verzió, GUI-val), az csak egy példányban indul. Ez egy feature a putty-ban, vagy én maradtam le valamiről?

Próbáltam nem a startDetached() -el indítani programot, és utána leválasztani, de ezt a Qt nem támogatja, a meghekkelése ugyan egyszerű, csak nem működik (10 sec után kilép a putty).

Igazándiból az lenne jó, ha a GUI egy tab-jában (QTabWidget) tudnák indítani egy terminált, vagy ssh-t.

  • 690 megtekintés

( x-daemon | 2021. 03. 31., sze – 21:31 )

valami libbel nem lehet megoldni? pl. libssh-t nem lehet hozzaforditani? vagy az nem ilyenre valo?

neked aztan fura humorod van...

A Qt-hez találtam egy QTerminalWidget osztályt, ami ezer példányban elforkolva, nem Windows kompatibilis, és combos függőségei vannak. Van valami Windows portja, de azt meg csak hiányosan tudtam letölteni, zéró dokumentációval. Se időmilliomos, se mazochista nem vagyok.

Nem Qt-s könyvtárral nem próbálkoztam még. Nem tudom, hogy egy libssh hogyan fog egy QWidget-tel összedolgozni.

( benz | 2021. 04. 01., cs – 00:31 )

Mostanában a windozban is van ssh. Ne szopj a puttyal ha nem muszáj.

Win 10 van csak, legalább ez nem gond. Sokadik Google találat, a Win 10-ben tényleg van már ssh (fantasztikus!), persze konzol, azt pedig külön cifrázni kell. A putty annyiban lett volna jó, hogy GUI, jól paraméterezhető, tud telnet-et is, eddig nem volt vele probléma. Ez a három példányban indulás pedig elég meglepő feature.

Nem szeretek Windows programokat vadászni. Sok a találat és sok szemét, nem megbízható forrás.

Halkan megjegyzem, ha eddig multiplatformos programfejlesztésre adtam a fejem, akkor szinte mindig a Windows-al kellet szívni. Legutóbb egy WLC-Qt könyvtárat használó programom lett Windows alatt lefordíthatatlan, mert a VLC SDK nincs benne az új VLC-be, letölteni sem lehet, csak forrásból lefordítani az egész VLC-t, azt pedig a függőségeivel fordítsa le az akinek hat anyja van. Linux alatt apt-get -tel letöltöm ami kell, működik, és az automatikus frissítés sem cseszi szét az egészet, akkor sem ha van frissítés. Ehhez a projekthez pedig a net-snmp -t nem tudom lefordítani Windows alá, bináris nincs, a letölthető forrás ezer éves. Az látszik, hogy valakik, valamikor megcsinálták a Windows portot, de dokumentálni már nem volt kedvük. Karbantartani pedig nem kell a net-snmp -t mert már végleges és tökéletes is (na ez speciel nem a Windows sara, és úgy általában az SNMP-vel is csak szívni lehet).

( persicsb | 2021. 04. 01., cs – 11:19 )

Nem annyi példányban indul el véletlenül, mint ahány profil van tárolva PuTTY-ban? Mi a parancssor, amit végrehajtatsz?

A kiadott parancs, telnet kliensként:

putty -telnet <ip>

Nincsenek tárolt profilok. De kipróbáltam egy Win.Domain-en kívüli virtuális géppel, frissen installált putty-al és ott csak egy példány indul. A "hárompéldányos" Windows  (Server 2012) egy terminál szerver. És most esett le a tantusz, ez nem is a Windows 10 szerver változata, így ssh sincs benne még.

( zitev v | 2021. 04. 01., cs – 17:34 )

"Linux alatt nincs ilyen jelenség, és persze putty sem."

- emlekeim szerint van putty linuxra is.

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

( NevemTeve | 2021. 04. 01., cs – 21:41 )

Szerkesztve: 2021. 04. 01., cs – 21:42

Ha nem C++ lenne, akkor azt mondanám, hogy érdemes lenne debuggolni. Mondjuk megállni a CreateProcess című függvényen és számolni a hívásokat.

( vl v | 2021. 04. 02., p – 16:21 )

Ez a tipikus esete annak, amikor az ember választ a projekt elején technológiát meg architektúrát, az aktuális tudása meg az állapotok alapján, aztán menet közben derülnek ki dolgok.

Pl. amióta nézem ezt a projektedet, azóta nem értem a vastag klienst meg a Qt-t. Meg persze az architektúrát sem, de nyilván ebben az is vastagon benne van nálam, hogy én részt vettem 15-20+ éve egy bizonyos típusú hálózati eszközöket menedzselő szoftverprojektben, és még emlékszem, hogy milyen döntéseket kellett meghozni, és mik voltak a szempontok, és aztán miből lett később gond és mi volt baromi jó választásunk.

Szóval ha ma megkérdeznél, hogy milyen stackre csinálnék hálózati monitorozást, az tuti, hogy a következő technológiák nem lennének benne:
- vastag kliens (vs webböngésző), vagy ha mindenképpen kell valami vastagkliensszerűség akkor az biztosan egy standard webböngésző motorra épülne
- Windows bármi másra, mint megjelenítésre, ami ugye az előző alapján egy szál web böngésző (vagy a motorjára épülő valami) lenne
- net-snmp (anno 2 hónapig néztük, hogy mit lehetne ezzel kezdeni, aztán újraimplementáltam a nekünk kellő részeket egy hét alatt - pár képernyőnyi kód volt az a kód, ami kellett belőle, a MIB parser volt az egyetlen, amit meghagytunk as-is)
- a gyűjtött adatok RBDMS sorokban egyesével tárolva (baromira drága I/O-ban, nem skálázódik értelmesen)
- monolit, single-machine, böhöm izék (vs elosztott, skálázható, microservice-alapú architektúra, újrahasznosítva a mások által megírt open-source dolgokat: Prometheus, Grafana, és haverjaik)
- (le)fordított nyelvben megírt komplett cucc (vs moduláris, script típusú nyelvben custom kóddal bővíhető architektúra)

Bizonyára van igazság abban amit írsz. De jó pár állításod egyszerűen nem igaz a projektre. Nem tudom mennyi időt szántál rá, de tartok tőle, hogy jóval kevesebbet, mint ami a projekt teljes megértéséhez, vagy átlátásához szükséges. Az utolsó állítás alapján a dokumentációt sem olvastad el.

A vastag kliens, az hogy került ide?

De jó pár állításod egyszerűen nem igaz a projektre

Egyáltalán nem azért írtam ezeket, mert a projektedre jellemzőek kivétel nélkül. Ezek azok a tanulságok, amiket az elmúlt 20 év alatt összeszedtem. Egy része nyilván igaz a projektedre, mások "csak" olyan zsákutcák, amikbe a konkurens open-source projektek masíroztak be rendre.

Ami biztosan igaz rá, hogy nem böngésző(motor)t használsz felületnek. Ebből szerintem rengeteg sok meló, és egy pár limitáció adódik. Böngészőmotorral pl. lehetne olyan megoldásokat használni, mint a Guacamole projekt SSH terminálja. És akkor mehetne a szerveren keresztül proxyzva a terminálforgalom, és nem kéne kötelezően a kliens PC-nek direkt hozzáférést adni a hálózati eszközökhöz.

jóval kevesebbet, mint ami a projekt teljes megértéséhez, vagy átlátásához szükséges

Ez egészen biztosan így van. De ennek igen erős gátja az, amit eddig láttam benne. Bocs.

A vastag kliens, az hogy került ide?

Idéznék a doksidból: "A GUI induláskor, ha problémát észlel, nem tud csatlakozni az adatbázishoz, vagy annak a verziója nem megfelelő, akkor hiba üzenetet ad, és egy alap menüt jelenít meg a setup-al."

Na nálam az a GUI, ami az adatbázishoz akar csatlakozni, az erősen vastag kliens. A GUI-nak emiatt szüksége van az adatbázis jelszóra. És ebből a felállásból nagyon nehéz bármi mást kihozni, mint kooperatív multi-userkedést, ahol kb. minden felhasználó admin.

Hát, igen, jó pár nyílt-forrású rendszer jellemzője, hogy nem egy "tudományosan" összeállított projekt alkotása, hanem egy igényből fakad, ami nem társul a mindentudáshoz. Terhelve azzal, hogy jelentős kapacitáshiánnyal küzd. Hallatlan előnyük ugyanakkor, hogy sokszor azok írják/tervezik, akik használják. Nem egy menedzser határozza meg, mi legyen benne, mit tudjon, hogy eladja magát, a másik menedzsernek.

Ennek a projektnek volt egy előző verziója, az PHP volt, jóval kevesebb SQL tapasztalattal (nem mintha most már SQL guru lennék). Ez részben azért lett Qt és C++, mert ahhoz jobban értek, és ki akartam próbálni egy programozási stílust, aminek kezdeményeit már más projektekben kipróbáltam. És erre a programra volt igényem nekem, mivel rendszergazda vagyok főállásban egy egyetemen. Sőt, meggyőződésem, hogy a többi karnak is lenne erre igénye, csak a rektorátusnak nem tetszik, hogy az egész egy tizedrangú beosztottól függ. Rettegnek attól, hogy rajtuk kívül esetleg valaki fontossá válik (ezt nem szó szerint nem így, de közölték is), és nem kirúgható azonnal (ezt csak én következtettem ki).

A közvetlen adatbázis kapcsolatot én is problémának tartom. De a közvetlen kapcsolat a lényege annak, amit ki akartam próbálni, programozás technikailag, ha ingyen dolgozunk, nem árt egy kis plusz motiváció. Ugyanakkor, ez nem egy olyan program, amit mindenkinek a feneke alá tolunk, jobbára azok használják, akiknek amúgy is rendszergazdai joguk van. A program szolgáltatásai is inkább egy kissé kaotikus egyetemi hálózathoz igazítottak, nem pedig egy paranoiás, minden a helyén van rendszerhez. Utóbbiakat akkor is lebeszélném a használatáról, ha esetleg eszükbe jutna ez az őrültség. Egy rosszul dokumentált, kissé kaotikus, és kellően nagy egyetemi hálózaton viszont nagyon jól használható, mivel részben helyettesíti a dokumentációt, ill. bizonyos szempontból több is annál (és ez a lényege, nem a Nagiost akartam újra írni).

Végül idéznék egy régebben látott plakátról: "Fikázni könnyű, alkotni nehéz.". Szerintem sommás véleményt mondani valamiről, amit nem ismerünk kellő mélységben, az erősen vitatható tevékenység, akkor is, ha van magyarázatunk.

Ui.: köszi az ötletet, a Guacamole projekt SSH terminálját megnézem, kicsit máshogy, de használható lehet, pont olyan megjelenésben, ahogyan akartam.

( YleGreg | 2021. 04. 03., szo – 20:50 )

Az eg kek, a fu zold, a Windows hulye. 

Szerintem ne pazarolj a feltetlen sziksegesnel tobb idot egy olyan rendszer uriemberkent valo hasznalatara, amely nem szolgalt ra a bizalmadra.

Keruld meg a problemat, peldaul indits el a programodbol egy .bat allomanyt, ami a hatterben elinditja a putty-ot. A windows meg bekaphatja. :-)

-1: amikor programozol, főleg ilyen alap dolgot, akkor ugyan van némi különbség, de alig valami. Az OS függő kódom alig 50-60 sor egy igazán nagy projektben, ahol minden is van. Mondjuk process-ek tényleg mások, mert nem fork van, de őszintén szólva a napi dolgokhoz a Windows-os CreateProcess nekem jobban kézre áll.

https://naszta.hu

Nem vagyok az a veresszaju windows hater aki Windows lepket majszolo Tuxos poloban maszkal a varosban, de a Windows lehulyezese igenis hasznos.

Regen amikor ifju voltam es boho, es volt idom mindenre, akkor a hulye rendszerek problemait hajlamos voltam megjavitani, de mostanra mar beletorodtem, hogy kar az idomert. Linux alatt az ember megkeresi a hibat, megerti miert van es kijavitja, mert tiszteli a rendszert es a letrehozoit.

Windows alatt en mar elvesztettem az erdeklodesemet, nem akarom megerteni, csak annyit hasznalom amennyit muszaj, mert csak felidegel hogy mennyivel gagyibb pedig meg fizettem is erte.

Szerencsere nem fejlesztek Windows ala, amikor pedig megis, akkor Python es joccakat. A QT kornyezetet nem ismerem, nem tudom, hogy a processz inditas kornyeken milyen taposoaknak vannak a windowsos portjaban. En tutira egy wrapper .bat file hasznalataval kerulnem ki a problemat, tudom, nem elegans, de mint irtam, Windows alatt en mar nem akarok elegans lenni. Minek? Hogy eltorjon a kovetkezo frissiteskor amikor megint atfirkaljak az UAC -ot? Annyit nem er a dolog szamomra.

En hasznalok .bat -ot arra, hogy a desktoprol egy duplakattal elindithassak 6 darab ssh konzolt, mert van egy olyan periodikus munkam aminel ugyanarra a 6 gepre kell bemenni. Ezek az inditasok mukodnek putty session betoltessel es ip-re valo hivatkozassal is, es mindegyik csak egy peldanyban nyilik ahogy kell, az indito .bat ablaka pedig egybol bezarul ahogy elinditotta az utolsot is.

Errol tudom, hogy mukodik, ezert tanacsoltam.

De megertelek, ha elegansabban szeretned megoldani, sot, tisztellek erte, hogy workaround nelkuli tisztesseges kodot akarsz a kezedbol kiadni!

( apal v | 2021. 04. 04., v – 18:09 )

A Qt-n kivul esetleg valami mas API-hivas? Linux alatt sem biztos hogy a Qt::WhateverObfuscatedLayer::CreateSomeProcessSomewhere(...)-rel hanem siman fork() + execve() kombinacioval probalkoznek eloszor :)