Linux-haladó

Sshfs-sel kapcsolódok egy proftpd szerverhez - a mod_sftp modulon keresztül -, szinte teljesen gond nélkül.

Mindent rendben megcsinál, de ha egy fájlt felül akarok írni mc-vel, akkor hibaüzenetet ad az mc, hogy engedély megtagadva.

Törölni tudok a szerveren, létrehozni is tudok. A fájlt más néven felmásolni, és mv paranccsal átnevezni is tudom. Csak felülírni nem.

A feltöltő felhasználónak van írási és olvasási joga is a fájlokra.

Ráadásul úgy tudtam, az mc biztonságos módban másol, tehát nem rögtön felülírja a felmásolandó fájlt, hanem először ideiglenes néven feltölti, és csak fent nevezi át a végleges nevére. Ezek után még kevésbé értem, mi okozza a hibát, és ötletem sincs, hogyan oldjam meg, azaz hogyan tudjak felülírni fájlokat.

Próbáltam már a mountnál opciókkal, de egyik sem vezetett eredményre. Sem az umask, sem az sshfs workaround opciói, sem egyéb, amit esélyesnek találtam.

Találkozott már valaki hasonlóval? Tud rá megoldást? Vagy van valakinek valami ötlete?

Megoldás:

Az "AllowOverwrite on" értéket az sftp konfigjában külön is meg kell adni, akkor is, ha a proftpd.conf-ban már meg volt adva.

Sziasztok,

ki milyen monitoring szoftvert ajánlana és miért? :)

Sokáig használtam Nagios-t, de az elég régen volt (5-6 éve), akkor átálltam Icingára.

Most szerver upgrade van, és nem biztos, hogy Icingát tennék vissza.

A peremfeltételek:

• a klienseken Nagios agent-ek vannak jó lenne, ha nem kellene végigmenni minden gépen újratelepíteni (bár ez még akár megoldható lenne), és beállítani (na ez már időigényesebb)
• ezen kívül van pár saját plugin, ezt sem akarom nagyon átírni
• szinte csak és kizárólag Linux, azon belül 95% Debian a monitorozandó host
• néhány Windows van, ahol figyeljük a CPU-t, mem-et, diszk telítettséget

Kollektor nem kell, de vissza lehessen nézni, hogy mikor milyen események voltak, mondjuk 1 évig. Szerepkörök, jogosultság kezelés mindenképp kell - de ezek gondolom alapból vannak.

Jó lenne mindent a felületről megcsinálni, ill ha lenne clusterezési lehetőség, tehát másik gépre is tenni egyet, és failover céllal, valamint ha egy host/service az egyikről nem érhető el, akkor be tudjam állítani, mit mondjon nekem a program.

Köszi.

Adott egy Debian Buster, több hálókártyával, hálókártyánként több vlannal, és esetenként vlan-onként több IP címmel.
Az egész a /etc/systemd/network -ben felkonfigurálva.

Időnként szeretnék ideiglenesen módosítani rajta, és használom a szokásos parancsokat:
ip addr add ...
ip route add ...

Szépen működnek is első ránézésre, de 1-2 nap után ezek a módosítások egyszerűen eltűnnek!
Gondolom, valami újra tölti az /etc/systemd/network alatti konfigokat. De miért, és mikor, és miért pont akkor? És hogy csináljak úgy változtatást, hogy azt csak én állítsam vissza?

Írjam bele mindig a konfigokba, aztán networkctl reload? Nincs valami "tisztább" módja?

Sziasztok!

Kb egy honapja kuzdok ezzel a hibaval, de nem jovok ra, mi lehet a gond.. mar nyitottam issue-t githubon, de sajna nem jott meg erdemleges valasz... Valakinek van otlete?

https://github.com/uyuni-project/uyuni/issues/3887

Sziasztok!

Adott egy Zentyal 7-es telepítés (development edition). A belső hálózat négy VLAN-ra van szétszedve:

• 1 - MENEDZSMENT - 192.168.50.0/24
• 5 - LEGACY - régi alhálózat - 192.168.5.0/24
• 51 - PUBLIC - vendég hálózat - 192.168.51.0/24
• 52 - INTRA - belső hálózat - 192.168.52.0/24

Kívülről, WAN irányból van néhány DNAT (port forward) létrehozva Zentyal GUI alól. A 80-as és a 443-as (HTTP, HTTPS) portok az 5-ös VLAN egyik gépére mutatnak (192.168.5.110). Ez eddig szuper, kívülről elérhető a szerver. Nade bentről nem. Bent alatt a PUBLIC és az INTRA hálózatokat értem. Az elegáns megoldás, a split DNS nem járható út, olyan gyorsan változik a kiszolgált hosztok köre, hogy nem tudnám menedzselni. Szeretném megoldani hogy a tűzfal (Zentyal) hairpin NAT segítségével elvégezze a megfelelő NAT-olást. Egyedi tűzfal szabályok a /etc/zentyal/scripts/firewall.postconf állományban létre hozhatóak, de akárhogyan próbálkozom, nem sikerül elérni a DNAT-olt szervert. Van aki csinált már ilyet? Ha igen, neki hogyan sikerült? Köszönöm!

Sziasztok!

Segítsetek, kérlek, eddig nem találtam rá megoldást.

Van egy Debian alapú fájl szerver, rajta több Samba megosztással. A gépen vannak felhasználók, valamint csoportok. Minden felhasználó tagja természetesen a Users csoportnak, ezen kívül van Peénzugy, Informatika, Vezetes, Raktar, stb csoport. Valamint van egy eSzamla nevű csoport is.

A szerveren vagy egy mappa, amit szeretnék megosztani:

    - Útvonala: \\srv\data1\e
    - Megosztás neve: eSzamla

A következőt szeretném megoldani:

    - A \\szerverem\eSzamla útvonalra minden felhasználó tudjon írni (pontosabban az ügyviteli rendszerünk mentené ide az elektronikus számlákat)
    - Ugyanez igaz bármely felhasználó által létrehozott almappára (az elektronikus számlák mappastruktúrába kerülnek Cég\Év\Hónap\számlaszám.pdf formátumban.)
    - A megosztáson levő állományokat listázni, olvasni csak az eSzamla csoport tagjai tudják
    - A tökéletes megoldás netovábbja lenne, ha a megosztásról csak az Informatika tagjai tudnának törölni

Mit kellene ehhez megadnom az smb.conf-ban? Egyáltalán megoldható ez a mód?

Gábor

Sziasztok!

Elég fura problémába futottam bele, talán ti tudtok segíteni megoldani.

A gépemen Ubuntu 18.04 x86-64-en az

ls -1 /etc/ssl/certs/ | wc -l

eredménye nálam: 266

Ha Dockerben futtatom az Ubuntu 18.04-es ARM imaget, akkor 259

docker run --rm -it --platform linux/arm/v7 ubuntu:18.04

Raspberry PI 2-n a Raspbian GNU/Linux 10 (buster) alatt 275

Ha ugyanezen az RPI-n futtatom Dockerben az Ubuntu 20.04-et, az 259 (a --privileged oka: https://askubuntu.com/a/1264921)

docker run --rm -it --privileged ubuntu:20.04

Ezek eddig jók. Viszont ha a gépemen futtatom ugyazent az ARM-os Ubuntu 20.04-es imaget Dockerben, akkor 130

docker run --rm -it --platform linux/arm/v7 ubuntu:20.04

Extra meglepetés: az Ubuntu 18.04-es ARM-os image a Dockerben jó, 259

docker run --rm -it --platform linux/arm/v7 ubuntu:18.04

A kérdés az, hogy a Dockerben emulált ARM-os környezetben Ubuntu 20.04 alatt miért hiányoznak a certek? Az update-ca-certificates parancs megvolt minden esetben. Így nem tudok semmit sem futtatni benne, ami SSL-t használna (wget, pecl), mert minden a certeket hiányolja:

docker run --rm -it --platform linux/arm/v7 ubuntu:20.04 sh -c "apt-get update && apt-get install -y wget && wget https://pecl.php.net/get/uuid-1.2.0.tgz"

root@999d47488a4b:/# wget https://pecl.php.net/get/uuid-1.2.0.tgz
--2021-07-01 11:40:41--  https://pecl.php.net/get/uuid-1.2.0.tgz
Resolving pecl.php.net (pecl.php.net)... 104.236.228.160
Connecting to pecl.php.net (pecl.php.net)|104.236.228.160|:443... connected.
ERROR: cannot verify pecl.php.net's certificate, issued by 'CN=Certum Domain Validation CA SHA2,OU=Certum Certification Authority,O=Unizeto Technologies S.A.,C=PL':
  Self-signed certificate encountered.
To connect to pecl.php.net insecurely, use `--no-check-certificate'.

Szisztok!

Ubuntu alatt Remminát használok RDP kliensnek, Remmina pedig rdesktop-ot használja RDP-hez.
xfreerdp lényegesen funkció gazdagabb, kényelmesebb, etc …

Létezik xfreerdp-hez kényelmes, naprakész GUI?
Hasonló lenne a legjobb mint reminna.
A lényeg hogy csoportosítani lehessen a felvett kapcsolatokat, és egyedileg paraméterezni.

Sziasztok!

Adott több host, ahol pl. cpu-t mérünk.

Van egy renitens szerver, ahol magasabb a terhelés, ott fentebb kellene emelni a warning és critical szintet.

Hogy lehet megoldani, hogy ne kelljen a service-t klónozi és létrehozni egy olyan változatát, ahol a cpu limit magasabb.

Ez csak egy példa. Számtalan eset van, ahol egyedi szinteket kellene beállítani. Pl. hálózati eszköz magasabb hőmérsékleten van, máshol az már critical, de ennél ez az OK szint.

Aktív ellenőrzés van (tehát a nagios kérdez ki), minden paraméter a monitoring szerveren van, kliensen nem rögzítünk értékeket, így warning és critical szintet sem.

Köszönöm!

Próbáltam rákeresni, de valahogy mindenkinek az a kérdése, hogy hogy oldja meg, hogy ne lője ki az ssh a folyamatot, amikor kilép vagy megszakad. Nekem meg pont az a problémám, hogy a picsáért nem lövi ki?

Egy bash script fut, normál esetben amíg él a session, addig az alsó állapot van, majd amikor megszakad az ssh, akkor nem kilövi, hanem felkerül a systemd alá...

systemd─┬─acpid
        ├─agetty
....
        ├─mgmt-host-onlin───sleep
....
        ├─sshd───sshd───sshd───mgmt-host-onlin───sleep

....

Wtf, miért?

Plusz infó, hogy mindezek mellett az a furi, hogy az sshd nélkül közvetlen a systemd alatt futó script bár ott van mint process, nem is zombi, látszólag fut is, de gyakorlatilag nem (írnia kéne egy fájlba, de nem ír).