Debian GNU/Linux

Megint Nagios :)

Fórumok

Sziasztok!

Lenne egy kis gondom Nagios nyomtató beüzemelésnél... a ping megy de a Printer Status:

(No output on stdout) stderr: execvp(/usr/local/nagios/libexec/check_hpjd, ...) failed. errno is 2: No such file or directory

 

A rendszer frissen telepítettett

 5.10.0-19-amd64 #1 SMP Debian 5.10.149-2 (2022-10-21) x86_64 GNU/Linux

A nagiost így telepítettem
https://computingforgeeks.com/install-and-configure-nagios-on-debian-10…

A modulok: nagios-plugins-2.4.2.tar.gz

A modulokat telepítettem rootként

cd nagios-plugins-$VER

./configure --with-nagios-user=nagios --with-nagios-group=nagios 

make

make install

És a libexec-ből hiányzik a check_hpjd...

Megnéztem a check_hpjd.c ott van, csak nem fordul le... Tud valaki tanácsot adni?

Debian nem boot-ol HP Elitebook 8460P laptopon

Fórumok

Sziasztok!

 

Adott egy Elitebook 8460P, ami pendrive-ról gond nélkül bootol Windows-t. BIOS módban van a laptop (tehát nem UEFI).

 

A probléma, hogy sem Debian telepítőt, sem GRML- tde még csak Ubuntu-t sem hajlandó bootolni. Amit eddig már megtettem, hogy kipróbáltam más BIOS és UEFI gépeken, persze minden megy hibátlanul.

Azt is megpróbáltam, hogy az SSD-t egy USB-s SATA átalakítóval leformáztam egy másik gépen, csináltam egy boot partit a GRUB-nak (ef02 típusút a fdisk-ben), és egy adatpartit (ext4) és debootstrap-pal felhúztam egy Debian-t, de így sem hajlandó bebootolni. Azt írja, hogy nincs bootolható OS a lemezen.

 

A helyzet tehát a következő: A Windows, de csak is a Windows feltelepül rendben és fut is. Viszont sem a GRML, sem a Debian installer nem bootol pendrive-ról a négy USB port közül egyikben sem, illetve a másik gépen telepített SSD-ről sem hajlandó bebootolni a Debian-t.

 

Mit tudnék még megpróbálni? A BIOS a legfrissebb és alaphelyzetbe is állítottam, hogy biztos ne legyen ezzel probléma.

[MEGOLDVA] Let's encrypt nem frissül

Fórumok

Van egy kissé kopott Debian 10.13 házi szerverem. Most már a második figyelmeztetést kapom, hogy lejár a let's encrypt certificatem. A kis RoundCube -hoz kell, hogy ne kelljen folyton restrikciókba ütköznöm, ill. a jelszó titkosítás miatt.
Évek óta nem volt vele gondom. Még egyelőre működik, https://domain.név/roundcube
Először azt hittem rájöttem mi a gond, router csere után elfelejtettem a 80 -as portot ami kell ennek a cuccnak. Kifordítottam, de nem oldotta meg.

A "summázatban" ilyen hibajelzést kapok:

   http://domain.név/.well-known/acme-challenge/4VukLM2h_wQP9YstHWMDq7B43x…
   Error getting validation data

  To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address. Additionally, please check that
   your computer has a publicly routable IP address and that no
   firewalls are preventing the server from communicating with the
   client. If you're using the webroot plugin, you should also verify
   that you are serving files from the webroot path you provided.

Az IP címem publikus, de nem fix, a domain nevet a freedns.afraid.org -tól kapom.  Működik, az A/AAA rekordban az van aminek lennie kell (pillanatnyilag).
Próbáltam:

sudo certbot certonly --renew-by-default --apache -d domain.név

Még egyszerűbben:
sudo certbot renew

De mindig ugyanaz. Nem jön össze a "challenge". Mintha az apache2 nem kezelné, vagy nem tudom mi az a hosszú hivatkozás. Anno nem csomagból telepítettem a certbotot.

Mi lehet a hiba?

Telepítsem újra csomagból?

MEGOLDÁS: Buta! Mikor megújítottam a http (80 port) forwardot a routeren. Már csak az nem világos, mikor a router mögül "ránéztem" http://domain.név akkor azt láttam amit kellet, az apache alapértelmezett lapját. Az volt gyanús, hogy nagy nehezen a táblagépemen (miért ilyen keserves ott szerkeszteni az url -t) és nem találta. Buta, triviális hiba, két számot felcseréltem :(

openvpn daemon hiba

Fórumok

Sziasztok!

Összeraktam egy openvpn server config filet és 

openvpn --config server.conf

indítással elindul, fel tudok csatlakozni, nincs hiba. Utána ctrl-c-vel leállítom.

 

Viszont

service openvpn start

esetén a daemonba loggol és elhal:

TCP/UDP: Socket bind failed on local address 1194: Address already in use.

Exiting due to fatal error.

 

Ilyet még nem láttam, hogy valami deamonként nem ugyanazt csinálja, mint simán elindítva... ötlet?

 

Köszönöm

A

UPS - monit figyelés

Fórumok

Sziasztok!
Adott egy Legrand UPS, ami szereti sűrűn elveszteni az USB kapcsolatát a Debian géppel.
Ilyenkor a UPS monitorozó sw-je az adatok helyet "... something wrong ..." feliratot jeleníti meg. Azaz a http kapcsolat jó,
az USB nem. Gondoltam, mivel úgyis működik más okok miatt a monit program, nosza figyeljük az UPS weboldalát, és ha adatok
helyett a "wrong" szöveget tartalmazza, akkor usb reset.
Ezzel a monit configgal (bármit írok be a contentbe) mindig ok-t ad, sose alertet:
[egyelőre azért alert, mert tesztelem, ha ok, usbreset lesz]

check host upsmonweb with address a.b.c.d
   if failed
     port 8081
     content = "wrong"
  then alert

Mi bökhetek el?
Köszönöm, Roland

[MEGOLDVA] Fail2ban vs. nftables

Fórumok

Sziasztok,

Debian 11 alatt van mód arra, hogy az nftables alatt meg lehessen nézni, hogy milyen ip van blokkolva a fail2ban által? Mert iptables esetén volt erre lehetőség: iptables -L INPUT -v -n

Most csak azt látom a fail2ban alatt a defaut config actionban iptables, de az update-alternatives --get-selections iptables az nftables-re mutat, így valójában az nftablesbe teszi, a config alapján a filter tábla input chainbe. Működni működik is, csak furcsállom, hogy nem tudom kilistázni az nft paranccsal, hogy milyen active blokkolt ip-je van, vagy úgy listázni az összes rule-t, hogy ott lássam. Fail2ban-client-el látható csak egyedül.

Mit használtok Debian remote desktop szerver/kliens

Fórumok

Szeretnék egy Linux gép desktopját elérni - távolról, vagy épp mellette.
Fenn van az xrdp, ha nem indítom el az xwindow -t tudok csatlakozni az rdesktop -al, viszont ha elindítom a remote gépen az xwindow -t akkor nem tudok csatlakozni (mindkét oldalon ugyanazt a felhasználót használom).
Nézegetem a Linux -hozt való remote desktop programokat (tigervnc, remmina stb.) a leírásaik nem igazán beszélnek erről az esetről - távolról is meg lokálisan is bevagyok jelentkezve - lehet lehetetlent akarok?
Tudtok olyan megoldást amikor a lokális és a távoli felhasználó azonos?

[MEGOLDVA] nm-applet systray ikonja nem látszik a polybar alatt Debian 11 esetén

Fórumok

Sziasztok,

Feltettem egy Debian 11.5-ös Minimal telepítésként, külön feltettem rá Xorg szükséges csomagjait (nem az összeset), egy Bspwm tilling windows manager-t, és az nm-applet (network-manager-gnome csomaggal jött meg) elindítva a polybar esetén egy üres hely jelenik meg, az ikon nem látható, és fizikailag sincsen ott, mert hiába kattintok nem jelenik meg a menü. Az érdekesség, hogy vannak olyan ritka pillanatok, mikor viszont megjelenik, mintha valami más kezelné a hálózati ikont a systemraybe. További infó, hogy az nm-tray-t felrakva sem jelenik meg az ikonja, viszont ott ha kattintok, akkor annak a menüje megjelenik. Ha a transmission-nek engedélyezem a systray ikonját, akkor az rendben megjelenik. Mintha csak a hálózati cuccok systray ikonjával csinálná ezt a galibát. A polybar-os fejlesztő azt mondja, hogy szerine a systray-t valami más alkalmazás használja, azért van ez a gond, de szerintem akkor semmilyen ikonnak nem kellene megjelennie. Külön furcsaság, hogy ha Arch linux-ot teleptek kézzel minimálba ugyanezzel a felállásban, akkor ott nincs ilyen probléma, így ez valami Debian specifikus "érdekesség" lesz. Notification-höz Dunst programot használok.

További infó, hogy ha polybar-t debeug info-ban indítom el, akkor sokszot ez látszik (de nem mindig):

warn: Systray selection already managed (window=0x1c00006)
* Deactivating tray manager
 

Vagyis olyaan mintha használná tényleg valami, de nem tudom mi, mikor minimal debian-t raktam fel, nincsen más ablakkezelő felrakva. Ha xprop -id -val lekérem a window után kapot értéket, akkor hibát dob, hogy nincs hozzá semmi, mintha nem létezne.

Annyit még érdemes tudni, hogy a .bash_profile -ból indítom a startx-et

[[ -f ~/.bashrc ]] && . ~/.bashrc
if [[ "$(tty)" == "/dev/tty1" ]]
 then
   startx
fi

És a .xinitrc -ben indítom a bspwm-et:

exec bspwm

 

Van valakinek ötlete, hog Debian esetén mi okozhatja ezt a problémát?

 

MEGOLDÁS:

1. Az ablakkezelő startup file-jábe fel kell venni: dunst ~/.config/dunst/dunstrc &

2. Ha nincs fent, akkor a libnotify-bin -t fel kell installálni, és a xinit.rc file-ba bele kell írni: systemctl --user import-environment DISPLAY
 

CEPH: ceph osd require_osd_release ASSERT FAIL

Fórumok

Adott Ceph storage v16 (pacific),3 monitor (mon,mgr,mds) cca 60 osd.

Feladatul kaptam, hogy update-eljem v17-re(quincy), leállítás nélkül. A monitorok gond nélkül updated, de az első osd v17 nem indul. Kiderítettem, hogy a címben szereplő config elem - require_osd_release - túl kicsi: nautilus (v14). Nosza, emeljük meg: "ceph osd require_osd_release pacific". De ahelyett, hogy lefutott volna (vagy legalább hibaüzenetet küldött volna), kiakadt, és a ceph-mon service ASSERT FAILlal elszállt.

Itt akadtam meg, mert újrahúzni nem engedik meg (sok adat ~200TB, sok idő), igaz, ha a v16 monitoroknál eszembe jut, akkor még valszeg lefutott volna a módosítás, és a v17 osd-k simán elindulnak, de most már nem tudom visszarakni v16-ba a monitorokat (csak ha leállítom az egész storage-t, talán).

 

Valaki CEPH mágus adhatna valami ötletet, ilyenkor mi a teendő.

Bemásolom ide, ami érdekes lehet:

./src/mon/OSDMonitor.cc: 11618: FAILED ceph_assert(osdmap.require_osd_release >= ceph_release_t::octopus)

 ceph version 17.2.1 (2508b9f16ef63944cb33be33a271b10931071205) quincy (stable)
 1: (ceph::__ceph_assert_fail(char const*, char const*, int, char const*)+0x124) [0x7ff26673423c]
 2: /usr/lib/ceph/libceph-common.so.2(+0x2593da) [0x7ff2667343da]
 3: (OSDMonitor::prepare_command_impl(boost::intrusive_ptr<MonOpRequest>, std::map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::variant<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, long, double, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::vector<long, std::allocator<long> >, std::vector<double, std::allocator<double> > >, std::less<void>, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, boost::variant<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, long, double, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::vector<long, std::allocator<long> >, std::vector<double, std::allocator<double> > > > > > const&)+0xbe8e) [0x5652021c99ae]
 4: (OSDMonitor::prepare_command(boost::intrusive_ptr<MonOpRequest>)+0x38f) [0x5652021d9dbf]
 5: (OSDMonitor::prepare_update(boost::intrusive_ptr<MonOpRequest>)+0x173) [0x5652021e3313]
 6: (PaxosService::dispatch(boost::intrusive_ptr<MonOpRequest>)+0x2ce) [0x565202160a0e]
 7: (Monitor::handle_command(boost::intrusive_ptr<MonOpRequest>)+0x1fb0) [0x5652020371f0]
 8: (Monitor::dispatch_op(boost::intrusive_ptr<MonOpRequest>)+0x5a3) [0x56520203ac83]
 9: (Monitor::_ms_dispatch(Message*)+0x41e) [0x56520203be8e]
 10: (Monitor::handle_forward(boost::intrusive_ptr<MonOpRequest>)+0xc39) [0x56520203d7a9]
 11: (Monitor::dispatch_op(boost::intrusive_ptr<MonOpRequest>)+0x1104) [0x56520203b7e4]
 12: (Monitor::_ms_dispatch(Message*)+0x41e) [0x56520203be8e]
 13: (Dispatcher::ms_dispatch2(boost::intrusive_ptr<Message> const&)+0x59) [0x56520206b6a9]
 14: (Messenger::ms_deliver_dispatch(boost::intrusive_ptr<Message> const&)+0x468) [0x7ff26697baf8]
 15: (DispatchQueue::entry()+0x5ef) [0x7ff2669791ff]
 16: (DispatchQueue::DispatchThread::entry()+0xd) [0x7ff266a3a59d]
 17: /lib/x86_64-linux-gnu/libpthread.so.0(+0x8ea7) [0x7ff26622cea7]
 18: clone()

2022-09-08T10:15:51.912+0200 7ff25e59a700 -1 *** Caught signal (Aborted) **
 in thread 7ff25e59a700 thread_name:ms_dispatch

ceph versions
{
    "mon": {
        "ceph version 17.2.1 (2508b9f16ef63944cb33be33a271b10931071205) quincy (stable)": 3
    },
    "mgr": {
        "ceph version 17.2.1 (2508b9f16ef63944cb33be33a271b10931071205) quincy (stable)": 3
    },
    "osd": {
        "ceph version 16.2.9 (a569859f5e07da0c4c39da81d5fb5675cd95da49) pacific (stable)": 50
    },
    "mds": {
        "ceph version 17.2.1 (2508b9f16ef63944cb33be33a271b10931071205) quincy (stable)": 3
    },
    "overall": {
        "ceph version 16.2.9 (a569859f5e07da0c4c39da81d5fb5675cd95da49) pacific (stable)": 50,
        "ceph version 17.2.1 (2508b9f16ef63944cb33be33a271b10931071205) quincy (stable)": 9
    }
}

ceph osd dump

...
flags noout,sortbitwise,recovery_deletes,purged_snapdirs,pglog_hardlimit
crush_version 531
full_ratio 0.95
backfillfull_ratio 0.9
nearfull_ratio 0.85
require_min_compat_client pacific
min_compat_client luminous
require_osd_release nautilus
stretch_mode_enabled false
...