zeller blogja

Itt amit legutóbb jakubovics művelt, az pontosan ilyen szándékos rombolás. Remélem, az életben majd visszakapja valahogy - például egy rosszindulatú támadótól... De elég, ha csak a munkaadója rájön, hogy milyen bunkón is tud viselkedni "anonim" környezetben.

Keepalived volt: 1.3.9,  lett 2.0.19, és örömmel tapasztalom, hogy "Warning - script chk_haproxy is not used" üzenettel örvendeztet meg - és tényleg tudomást sem vesz arról, hogy a haproxy fut-e vagy sem...

Volt szerencsém néhány fizikai gépet pátyolgatni, amikben nettó 2TiB-nyi háttértár kapott helyet. Ezekre évekkel ezelőtt került Linux, no GPT, csak MBR, egy /dev/sda1 ext3, és a /dev/sda2 mint pv került rá.

Telt az idő, és tárhelyet kell növeszteni... A RAID-tömböt a diszkek cseréje után az ssacli szépen megnyújtotta, viszont... 4TiB, ergo GPT kell, mindezt úgy, hogy reboot-ra és partíciók tologatására nincs mód/idő.

Szóval volt két fizikai gépem (RHEL8), amiből vm-et kell csinálni. Egyszerűnek tűnik: vmware standalone konverter, egy sudo (nopasswd) jogú user a fizikai gépen, gép létrehozására jogosult user a vmware-ben... Ja. meg az "apró"...

18 év után elég volt... Ja, és kösz a halakat!

Linux-on ha a datapatch -verbose olyasmit mond, hogy:
ORA-20001: Latest xml inventory is not loaded into table

2022 van, jó lenne az SSL/TLS-t értelmesen használni, nosza, próbáljuk meg, hogy az IMAP-ot így becsomagolva rávehető-e a kliens arra, hogy megadott certet használja a kapcsolat kiépítéséhez, illetve user/jelszó párost a bejelentkezéshez.

Néhány órás kísérletezgetést követően úgy tűnik, hogy ez olyan extra igény, amit nem tudnak/akarnak megugrani az IMAP-os levelezőkliensek - "asztali" verziókban sem, mobilban meg pláne... :-/

Marad az OpenVPN és az abba becsomagolt ssl-es IMAP...

Ha a realm join -v ...satöbbi... végén azt kapod, hogy:

 * Using GSS-SPNEGO for SASL bind
 ! Couldn't authenticate to active directory: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Configuration file does not specify default realm)
adcli: couldn't connect to pamparam.domain domain: Couldn't authenticate to active directory: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Configuration file does not specify default realm)
 ! Insufficient permissions to join the domain

akkor...

Egy Dell notebook-ban megpusztult az LCD (Chimei Innolux N156HGE-LG1 Rev. C2 (Dell P/N: 09FN4Y)), néminemű keresgélés után sikerült egy azonos tipust beszereltetni - kép van, működk - cska épp a fényerőt nem lehet állítani. A BIOS-ban az akkus/hálózati tápláláshoz a beállítás megvan, de az "Apply" gombra már nem lehet kattintani, és nem meglepő módon billentyűzetről vagy bebootolva programból sem lehet a fényerővel semmit sem csinálni.

Nem tudom, mire gyanakodjak? Kábel? Ez is egy (másképp) hibás kijelző? Vagy mi a franc...?

Van két site, mindkét helyen két-két fizikai gép, gépenként másfél TiB diszk (ssd), ami most egy plusz fél felosztásban működik, a kisebbikre megy a mentés, ami rsync-kel van a két site között szinkronizálva, a nagyobbik területen megy egy replikált DB fürt dolgozik.
Lassan kezd elfogyni a mentési terület, úgyhogy azon kezdtem el gondolkodni, hogy a négy gépen rendelkezésre álló mentési területből kéne egy hálózatos repliklát tárterületet csinálni, site és host szintű redundanciával.
 

Eltelt némi idő, és persze, hogy újabb módon szivat ez a (nem kicsit) drágaság: Két, elvileg egyforma DB, ugyanaz a "create or replace procedure...", és az egyiken simán lefut, a másikon meg "ORA-38824: CREATE OR REPLACE command may not change the EDITIONABLE property of an existing object." hiba van.

Naná, hogy nagyon fontos feldolgozás közben jön a hiba, PGA_AGGREGATE_LIMIT-be ütközés esete forog fenn. Akkor nézzük, miből főzünk, és mit, meg hogyan...
Elvileg semmi extra igénye nincs az alkalmazásnak (szállító nem jelezte, hogy kéne, sőt az XE-t elégnek tartotta mindenki...), úgyhogy nézzük meg, mi a franc ez a limit, és hogy lehet tornázni rajta.

Felment az Oracle, megvolt a mentés/visszaállítás kör is, szépen megy a standard. De. Csináltam egy másik gépet, ugyanazzal az Oracle verzióval, ugyanazzal a DB-kreáló scripttel és visszatöltött adatbázissal.
Lokálisan sqlplus user meg  sqlplus user@\"host.domain:1521/sid.db.domain\" működik, listener statusz (a host meg a sid kivételével) ugyanazt mutatja, mint az első gépen,viszont mig az elsőnek telepített szerverre távolról lehet kapcsolódni, úgy az újabbra nem, mert szép kövér ORA-12547-tel zavar el a búsba.

A két telepítés között emlékeim szerint annyi a különbség,hogy az elsőnél a sid az valami "abc", a másodiknál meg "efg.db.domain" lett.

Selinux permissive módban, a comagok eljutnak a listenerig, mert a listener logban ott van a nyoma - méghozzá olyan nyoma, mint a másik gépen, ahol sikerül bejelentkezni.

Sok éve regisztráltam a SamKnows projektbe, és néhány héttel ezelőttig jól is ment a mérés (bár a gigabites sávszélességet nem bírta mérni a doboz - újat meg nem küldenek már), viszont egy rövid áramszünet után megszűnt működni a motyó: power led, összes led, majd sötétség, és ez így 1-2s-es időközönként eljátszva.
Tipikus boot loop, flas image kéne rá - gondoltam én, úgyhogy levél a SamKnows supportnak, hogy döglött, kéne firmware... Azt ők nem adják ki ügyfélnek, és mivel az eszköz cseréjére sincs mód (elosztogatták az összes gigabitet mérni tudó dobozkát), javasolták, hogy ergisztráljak egy másik címmel, és ha lesz újra "osztogatás", akkor kaphatok másik accountot, másik eszközt...
No mindegy, én ezt az n600-ast szeretném életre lehelni, ha "eredeti" sam-os firmware-rel, akkor azzal, ha meg gyárival vagy épp valami 3rd party-val, akkor azzal.

Feladat: XE (18) migrálni 18 standard 2-re. A telepítő még csak-csak meglelhető a megfelelő user/pass használatával bejelentkezve az orákulum nagy felhőjébe, meg még a telepítése is megtörténik leírás szerint, de a dbua ezzel örvendeztet meg:

[DBT-20021] The current Oracle home /u1/oracle/product/18.3.0/dbhome_1 does not have the required Enterprise licence to perform the database move operation.

Ez most komoly, hogy az XE-Standard nem megy, csak XE-Enterprise, és majd az enterprise-ből kell downgrade...? Ki az a bárgyú barom, aki így csinálta meg?!

Ha valaki csinált már ilyen költöztetést, az ne tartsa magában a jótanácsait, illetve a tapasztalatait/howto-ját... Köszi. (A rendszer méretezését végsőket meg innen is csókoltatom, mert ugye melyikkorlátozásba sikerült belerongyolni? A DB méretbe...)

[Frissítés]

A dbua tudta jól, hogy enterprise kellene a célnál, merthogy partícionált táblákkal van megspékelve az XE-n futó adatbázis; az EE-ből készült dump az "ORA-00439: feature not enabled: Partitioning." okán nem ment be a megcélzott SE verzióba.
A következő lépés felsőbb szinten a fejek összedugása, hogy mi legyen, mert tippre nem "csak mert szebb" okból partícionálták azokat a táblákat...
 

bevallom, kapkodtam picit, így aztán sikerült kétszer öt méter RGBW LED-szalagot beszereznem, csak épp 5V-os és 3+2 eres csatlakozóval szereltet (WS2812B LED-ek), ami nagyon nem való a 12V-os vezérlőhöz, úgyhogy most vagy találok valakit, akinek épp ilyenre van szüksége, és ad érte mondjuk darabonként 6E "jó" magyar Ft-ot, vagy kitalálom, hogyan fogom meghajtani és hasznosítani - miután vettem hozzá 5V-os tápot, merthogy 12V-os van egy rakat...

Van egy speckó mikrokontrolleres eszköz, aminek néhány dolgot meg kell "tanítani" a normál működéshez. Ez meg is történt, viszont egy idő után ezeket "elfelejti" - újratanítást követően megint működik ideig-óráig, aztán goto 10, tanítható újra. A mikrovezérlő blokkdiagramja meg a panel tanulmányozása után úgy tűnik, hogy egy soros eeprom-ban kéne tárolódnia ezeknek az információknak, ami egyébként egy 9386-os tipus, "természetsen" SO8 tokban, úgyhogy inentől kezdve kéne valaki, aki ezt a gyanút igazolni tudná, illetve utána ezt dögöt ki tudná cserélni (M93C86-WMN3P) Budapesten. (A cserealkatrész beszerzését intézem, bát ahogy nézem, a legtöbb helyen a 80°C-ig használható darabokat lehet kapni...)

ERR_BAD_SSL_CLIENT_AUTH_CERT - mondja a Google Chrome... Az IE11 nem mondja (csak gondolja), viszont neki sem megy az adott cert-tel authentikáló oldal, úgyhogy ez sajnos darabra 2/3-ad, merthogy a Firefox tökéletesen veszi az akadályt, úgyhogy holnap a CA meg a certek világába kirándulok, mondhatni a Windows-os certstore sötét és méy bugyraiba kell majd leszállnom, úgy tűnik...

Nem az a kérdés, hogy belefut-e az ember, hanem az, hogy mikor, és persze hogy hogyan mászik ki belőle, mert az insert/update/delete a webes alkalmazás felől/felé működik szépen, a táblák utf8, a table status azt mondja, hogy utf8_general_ci a collation, viszont:

update VALAMI_TABLA set VALAMI_OSZLOP = SAJAT_FV(VALAMI_OSZLOP, 456567);
ERROR 1267 (HY000): Illegal mix of collations (utf8_general_ci,COERCIBLE)
 and (latin1_swedish_ci,IMPLICIT) for operation 'locate'

Van egy APC 6000-es (SRT6KRMXLI) UPS, és annak egy jófajta(?) beépített hálózati management kártyája (AP9537SUM).
Ez a dög a hosszú hétvége tiszteletére tökéletesen elfelejtette(!) a .1.3.6.1.2.1.33 (SNMPv2-SMI::mib-2) ágat, ergo a Zabbix-ban a nagy semmi látszik csak.
Hab a tortán, hogy a menüjében a "Configuration" alatt nincs "Communication" menü - szerencsére a hálózati beállításai egy reset után is megmaradtak - az SNMPv2 viszont nem jött vissza, sőt az Application Module-ra (telnet rulz) "Invalid Module Header!"-t mond.

Ha a CentOS alapú ESET appliance-t mostanában (27-e után, ugyanis akori dátummal jött ki a problémás odbc connector csomag) frissítetted, és a webes felületre nem tudsz bejelentkezni, akkor rakd szépen vissza a mysql-connector-odbc csomagból a 8.0.11-est, azzal menni fog.

Rég nem nyúltam komolyabban Perl scripthez, de most ismét eljött az ideje, hogy egy rendcsinálás és mentés/archiválás optimalizálás okán komolyabb eszközt vegyek elő.

Ami adott CentOS7 meg egy szééép MS-SQL szerver, természetesen Windows-on. A feladat fájok (naná, hogy ékezetes nevekkel...) pakolgatása a Linuxon, és ennek lekövetése az adatbázisban (útvonal+fájlnév egy mezőbe beírva, mert anno így lett kitalálva...)

Az UTF-8/Unicode szép és jó dolog, igaz, Perl-ben talán nem annyira egyszerű, de azért egyelőre úgy néz ki, sikerült megoldani.

a http://www.klasszikradio.hu/ jelenleg mondhatni eléggé érdekesen néz ki; arrafelé valaki kellően ügyes volt (ismét), úgy tűnik - a multkori játszási lista (DB hozzáférés letiltva) para után ez azért picit komolyabb :-)

Ki és miért talál olyasmit ki, hogy ha a feladó domainjéhez tartozó másodlagos MX nem érhető el, akkor a levelet nem hajlandó átvenni?

450 4.1.7 : Sender address rejected: unverified address: connect to drmx.###.hu[1.2.3.4]:25: No route to host (in reply to RCPT TO command))


Az persze más kérdés, hogy ezt úgy találta ki anno valaki, hogy a drmx csak akkor áll üzembe, amikor az egész motyó átborul a másodlagos infrastruktúrára, ami a fentiek miatt nagyon nem nyerő...

Aki CentOS7-en szeretne PDF-et nyomtatni, az ugye sínen van, mint ama híres költőnk, hiszen a cups nagyszerű dolog, és működik is. Kivéve, ha nem.

Tünet: bizonyos pdf fájlok helyett üres lapok esnek ki a nyomtatóból, az errorlogban men "stream keyword not followed by proper line terminator" hiba figyel.

Valóban, a pdf-ben a "stream és a "\r\n" között ott csücsül egy 0x20 szóköz... Workaroundként lehet egy jól irányzott sed 's/stream\ /stream/g'-vel megcsapkodni a pdf-et, de ez nem igazán "szép" - viszont működik.

RHEL hibajegy van, az upstream-ben (qpdf) már ott a javítás - jó kérdés, hogy ez mikor csorog vissza a RHEL/CentOS vonalra...