Linux-haladó

Sziasztok!

Aki a cimben szereplo programot hasznalja, attol kernek egy kis helpet!

Ti hogyan oldjatok meg a hostname automatikus beallitasat (VMware VM-eknel)?

Nalam ugy nez ki a dolog, hogy keszitettem egy kb 60 megas iso-t, amirol bebootolva a centos szepen feltepul az Uyuni serverrol (autoinstallation) majd egy post scriptel az Uyuni ala is berakja magat, a bootstrap-al megkapja a kezdo configot, feliratkozik a megfelo software channelre etc... Ez mukodik is szepen, de gondoltam tovabbfejesztem az alabbiakkal:

- beleptetes active directoryba (sssd, install utan felrakja, meg a dependency-ket is)

- sudoers beallitasa (AD group)

- Cockpit telepitese (wines kollegak ragaszkodnak hozza...:) )

- par alap progi felrakasa (check_mk, fail2ban, etc...)

Viszont ezek egy reszehez mindenkepp kell, hogy hostnevet adjak a gepnek, mielott barmi tortenne.... Wines gepeknel Ivanti DSM-et hasznalunk, ott vagy a VMwarebol atveszi a VM nevet, ha BIOS alapu a boot (policy nalunk, hogy a VM neve a hostname), vagy a DSMben kell elnevezni a gepet (UEFI boot eseten) igy legyegeben erintesmentesen foltelepulnek a win-ek. Hasonlot akarnek a linuxokkal is.

Csatlakoztattam a vCentert az uyunihoz, de azon kivul, hogy melyik regisztralt kliens melyik hoston van, masra nem igazan latom, hogy hasznalhato lenne ez a funkcio...

Szoval a kerdesem a kovetkezo. Ti hogyan oldanatok meg, hogy telepites vegen valahogy megkapja a megfelelo hostnevet a kliens?

(Ha lehet, uyuni oldalon oldanam meg, tehat pl nem akarnek ezert modjuk pyVmomi-t rakni minden kliensre)

Hello,

pár hónapos Debian 10, 2 SATA diszk, RAID 1. Sima upgrade után reboot, és a GRUB bootolni próbálna, de a subject-ben látható üzenetet kaptam.

Google - meglepő módon - nem adott találatot.

Ismét restartoltam a gépet, BIOS-ban megváltoztattam a diszkek sorrendjét, most bebootolt. Kipróbálom majd, hogy mit csinál, ha visszaállítom, de nem igazán értem a jelenséget.

Van valakinek ötlete, mi lehet ez?

Sziasztok!

PPP kapcsolaton átküldött adatmennyiséget szeretnék limitálni. Egyelőre úgy néz ki, hogy wvdial-lal építem fel a kapcsolatot (de ha van jobb módszer, az is érdekel), és nem szabad, hogy 100 KB-nál több adat menjen át rajta (küldött és fogadott együtt). Hogyan tudom egy bizonyos adatmennyiség után megállítani a kapcsolatot?
Van erre valami ötletetek?

Sziasztok!

A következő gonddal szívok (lehet nem látom a fától az erdőt):
Van egy proxmox szerver több vm-mel és ct-vel.
Alapértelmezetten a fizikai gép enp0s31f6 csatolója rendelkezik egy fix ip-vel. (mondjuk 1.2.3.4) Az egyik vm-nek is kellett egy fix ip (mondjuk 1.5.6.7) Ez megjelnik, mint vmbr1. A belső hálózat vmbr0 192.168.100.1 - ez a fizikai gép címe. A vm-nek a belső címe 192.168.100.105.

Szeretném, hogy a 21-es porton kívülről elérjem a vm 21-es portját.
A tűzfal szabályokba ezért felvettem a következő:

iptables -A FORWARD -i enp0s31f6 -p tcp -m tcp --dport 30000:50000 -d 192.168.100.105 -j ACCEPT
iptables -A FORWARD -i enp0s31f6 -p tcp --dport 20 -d 192.168.100.105 -j ACCEPT
iptables -A FORWARD -i enp0s31f6 -p tcp --dport 21 -d 192.168.100.105 -j ACCEPT
iptables -A PREROUTING -i enp0s31f6 -p tcp -t nat --dport 21 -j DNAT --to-destination 192.168.100.105:21
iptables -A PREROUTING -i enp0s31f6 -p tcp -t nat --dport 20 -j DNAT --to-destination 192.168.100.105:20
iptables -A PREROUTING -i enp0s31f6 -p tcp -m multiport -t nat --dports 30000:50000 -j DNAT --to-destination 192.168.100.105:30000-50000

Maszkolás bekapcsolva, ip forward bekapcsolva, pure-ftpd-ben felvéve a force passzív ip (1.5.6.7), passzív portok megadva (30000-50000)

Csatlakozásnál random módon hol csatlakozik, hol nem. Hiba üzenet ennyi:
mlsd
error the data connection could not be established econnrefused - connection refused by server
Két, három próbálokozás után, belép, majd megy egy ideig, majd a könyvtár listázásnál hal el. (filezilla)
ncftp-nél is észlelhető a hiba, de ott nem akad meg az egész ilyen látványosan
Mit rontok el?

Köszi!

Sziasztok

Adott egy frissen telepített FreeIPA. Szeretnék egy olyan sudocommand-ot csinálni mint amilyet a sudoers fájl megenged, vagyis hogy *-ozzak bizonyos parancsokat (pontosabban a paraméterezését)

Sajnos azonban a *-ot nem eszi meg ha freeipa-ból jönnek a szabályok.

Miként lehet *-os paramétert megetetni az IPA-val?

Előre is köszönök minden építő jellegű hozzászólást, segítséget.

Sziasztok!

Adott egy CentOS 7 Linux szerver, arra telepítve lett egy Freeipa szerver. Amit meg kell valósítani, hogy az IPA szerver WEBGUI felületén felvett /home/$user könyvtárak chrootolva legyenek. A felvett felhasználók azonosítója nem kerül be a /etc/passwd fájlb, hanem a PAM /etc/pam.d/* alatt lévő (pl sshd, login etc...) fájlokban vannak konfigurálva, illetve a /etc/security/chroot.conf fájlban. Ezen kívül ugyan a /etc/ssh/sshd_config ba is beállítottam a chrootot, de valószínű hogy ezt a /etc/security/chroot.conf fajlban kell, de ide hogy automatikusan chrootolja a mappákat felhasználóként, szükséges lenne  hogy tudom megadni a regex-el (format: username_regex chroot_dir), hogy ne kelljen külön a felhasználókat kézzel felvenni, amit a ipa szerver webes felületén felvettünk, hanem generálódjon ide le. Egyenlőre megpróbáltam a felvett teszt felhasználót beleírni direktbe a fájlba, de valami még nem kerek, mert a /var/log/secure logban ennyi látszódik, és még mindig ki tud menni a felhasználó a saját könyvtárából:

                           pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x user=tesztelek
Feb 11 08:27:00 freeipa sshd[16030]: Accepted keyboard-interactive/pam for tesztelek from x.x.x.x port 57232 ssh2
Feb 11 08:27:00 freeipa sshd[16030]: pam_chroot(sshd:session): /home/tesztelek is writable by non-root

Valakinek lenne erre ötlete? Hogyan lehetne megoldani?

Előre is köszönöm

Sziasztok!

Adott egy vdo mount ami az alabbiak szerint van parameterezve az fstab-ban

UUID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx /mnt/vdo1_share auto _netdev,x-systemd.device-timeout=0,x-systemd.requires=vdo.service,x-systemd.requires=mnt-nfs_share.mount,x-systemd.requires=loops-setup.service 0 0

a lemez amit fel kell mountolnia egy NFS share en levo qcow2 file (loop device-kent felmountolva, hogy tudja kezelni a vdo), ez az oka annak, hogy a mountnak meg kell varnia a 

mnt-nfs_share.mount

és a 

loops-setup.service

service-eket. 
 

a log szerint probalkozik elotte de mivel dependency baj van, nem sikerul neki, de elv miutan minden dependency teljesult, elinditja a vdo-t
 

Feb  5 14:41:50 hun25-18v systemd: Found device /dev/disk/by-uuid/7f264d4f-9cbe-4e3d-8b76-013f147272d9.
Feb  5 14:41:50 hun25-18v kernel: kvdo0:packerQ: compression is enabled
Feb  5 14:41:50 hun25-18v systemd: Started Device-mapper event daemon.
Feb  5 14:41:50 hun25-18v dmeventd[1785]: dmeventd ready for processing.
Feb  5 14:41:50 hun25-18v UDS/vdodmeventd[1758]: INFO   (vdodmeventd/1758) VDO device vdo1 is now registered with dmeventd for monitoring
Feb  5 14:41:50 hun25-18v vdo-by-dev: Starting VDO vdo1
Feb  5 14:41:50 hun25-18v vdo-by-dev: Starting compression on VDO vdo1
Feb  5 14:41:50 hun25-18v vdo-by-dev: VDO instance 0 volume is ready at /dev/mapper/vdo1
Feb  5 14:41:50 hun25-18v lvm[1785]: Monitoring VDO pool vdo1.
Feb  5 14:41:50 hun25-18v systemd: Started Start VDO volume backed by dev/loop0.

Ebben a vdostats is megerosit:

[root@hun25-18v ~]# vdostats
Device               1K-blocks      Used Available Use% Space saving%
/dev/mapper/vdo1     1073905920   5082244 1068823676   0%           99%

Viszont a mount mar nem tortenik meg

[root@hun25-18v ~]# df -h
Filesystem                                         Size  Used Avail Use% Mounted on
devtmpfs                                           1.9G     0  1.9G   0% /dev
tmpfs                                              1.9G   64K  1.9G   1% /dev/shm
tmpfs                                              1.9G  8.6M  1.9G   1% /run
tmpfs                                              1.9G     0  1.9G   0% /sys/fs/cgroup
/dev/mapper/centos-root                             38G  2.2G   35G   6% /
/dev/sda1                                         1014M  195M  820M  20% /boot
/dev/mapper/centos-home                             19G   33M   19G   1% /home
10.80.36.1:/raid0/data/_NAS_NFS_Exports_/R6BACKUP  5.2T  2.1T  3.2T  40% /mnt/nfs_share

A fura hogy a logban annak meg a nyomat sem latom, hogy megprobalja felmountolni a vdo lemezen levo xfs particiot.... Termeszetesen boot utan ha kezzel nyomok egy mount -a-t, akkor gond nelkul megcsinalja... Szerintetek mi lehet a gond?

Bocsanat, van nyoma(urbackupsrv-t ne nezzetek, az most nem szamit):

[root@hun25-18v ~]# cat /var/log/messages | grep vdo1_share
Feb  5 13:21:41 hun25-18v journal: Mounted /dev/dm-3 (system) at /mnt/vdo1_share on behalf of uid 0
Feb  5 13:40:07 hun25-18v systemd: Dependency failed for /mnt/vdo1_share.
Feb  5 13:40:07 hun25-18v systemd: Job mnt-vdo1_share.mount/start failed with result 'dependency'.
Feb  5 13:40:08 hun25-18v urbackupsrv: ERROR: No permission to access "/mnt/vdo1_share/urbackup_backup/urbackup_tmp_files"
Feb  5 13:46:19 hun25-18v urbackupsrv: ERROR: No permission to access "/mnt/vdo1_share/urbackup_backup/urbackup_tmp_files"
Feb  5 13:46:20 hun25-18v systemd: Dependency failed for /mnt/vdo1_share.
Feb  5 13:46:20 hun25-18v systemd: Job mnt-vdo1_share.mount/start failed with result 'dependency'.
Feb  5 13:51:44 hun25-18v systemd: Dependency failed for /mnt/vdo1_share.
Feb  5 13:51:44 hun25-18v systemd: Job mnt-vdo1_share.mount/start failed with result 'dependency'.
Feb  5 13:51:45 hun25-18v urbackupsrv: ERROR: No permission to access "/mnt/vdo1_share/urbackup_backup/urbackup_tmp_files"
Feb  5 14:00:18 hun25-18v systemd: Dependency failed for /mnt/vdo1_share.
Feb  5 14:00:18 hun25-18v systemd: Job mnt-vdo1_share.mount/start failed with result 'dependency'.
Feb  5 14:00:19 hun25-18v urbackupsrv: ERROR: No permission to access "/mnt/vdo1_share/urbackup_backup/urbackup_tmp_files"
Feb  5 14:08:09 hun25-18v journal: Mounted /dev/dm-3 (system) at /mnt/vdo1_share on behalf of uid 0
Feb  5 14:08:11 hun25-18v journal: Cleaning up mount point /mnt/vdo1_share (device 253:3 is not mounted)
Feb  5 14:09:07 hun25-18v journal: Mounted /dev/dm-3 (system) at /mnt/vdo1_share on behalf of uid 0
Feb  5 14:09:44 hun25-18v systemd: Dependency failed for /mnt/vdo1_share.
Feb  5 14:09:44 hun25-18v systemd: Job mnt-vdo1_share.mount/start failed with result 'dependency'.
Feb  5 14:09:45 hun25-18v urbackupsrv: ERROR: No permission to access "/mnt/vdo1_share/urbackup_backup/urbackup_tmp_files"
Feb  5 14:12:56 hun25-18v journal: Mounted /dev/dm-3 (system) at /mnt/vdo1_share on behalf of uid 0
Feb  5 14:14:52 hun25-18v journal: Cleaning up mount point /mnt/vdo1_share (device 253:3 is not mounted)
Feb  5 14:15:49 hun25-18v urbackupsrv: ERROR: No permission to access "/mnt/vdo1_share/urbackup_backup/urbackup_tmp_files"
Feb  5 14:15:50 hun25-18v systemd: Dependency failed for /mnt/vdo1_share.
Feb  5 14:15:50 hun25-18v systemd: Job mnt-vdo1_share.mount/start failed with result 'dependency'.
Feb  5 14:18:18 hun25-18v systemd: Dependency failed for /mnt/vdo1_share.
Feb  5 14:18:18 hun25-18v systemd: Job mnt-vdo1_share.mount/start failed with result 'dependency'.
Feb  5 14:18:20 hun25-18v urbackupsrv: ERROR: No permission to access "/mnt/vdo1_share/urbackup_backup/urbackup_tmp_files"
Feb  5 14:22:03 hun25-18v journal: Mounted /dev/dm-3 (system) at /mnt/vdo1_share on behalf of uid 0
Feb  5 14:23:20 hun25-18v systemd: Dependency failed for /mnt/vdo1_share.
Feb  5 14:23:20 hun25-18v systemd: Job mnt-vdo1_share.mount/start failed with result 'dependency'.
Feb  5 14:23:21 hun25-18v urbackupsrv: ERROR: No permission to access "/mnt/vdo1_share/urbackup_backup/urbackup_tmp_files"
Feb  5 14:26:48 hun25-18v journal: Mounted /dev/dm-3 (system) at /mnt/vdo1_share on behalf of uid 0
Feb  5 14:27:11 hun25-18v systemd: Dependency failed for /mnt/vdo1_share.
Feb  5 14:27:11 hun25-18v systemd: Job mnt-vdo1_share.mount/start failed with result 'dependency'.
Feb  5 14:27:12 hun25-18v urbackupsrv: ERROR: No permission to access "/mnt/vdo1_share/urbackup_backup/urbackup_tmp_files"
Feb  5 14:31:55 hun25-18v systemd: Dependency failed for /mnt/vdo1_share.
Feb  5 14:31:55 hun25-18v systemd: Job mnt-vdo1_share.mount/start failed with result 'dependency'.
Feb  5 14:31:56 hun25-18v urbackupsrv: ERROR: No permission to access "/mnt/vdo1_share/urbackup_backup/urbackup_tmp_files"
Feb  5 14:41:41 hun25-18v systemd: Dependency failed for /mnt/vdo1_share.
Feb  5 14:41:41 hun25-18v systemd: Job mnt-vdo1_share.mount/start failed with result 'dependency'.
Feb  5 14:41:45 hun25-18v urbackupsrv: ERROR: No permission to access "/mnt/vdo1_share/urbackup_backup/urbackup_tmp_files"

Olyan, mintha probalkozna, de feladja mire meg tudna tenni...

Rengeteg fórumot, ötletet kipróbáltam, de csak nem tudom megszüntetni a pislogást .

A hardver: Nvidia GT710 - nvidia driverrel. A monitorom csak VGA D-SUB csatlakozású. Asus VW220D 1680x1050

$ rpm -qa | grep nvidia
x11-driver-video-nvidia-current-460.32.03-1.mga7.nonfree

Paraméterek. 
   Option         "nvidiaXineramaInfoOrder" "CRT-0"
   Option         "metamodes" "nvidia-auto-select +0+0 {ForceCompositionPipeline=On, ForceFullCompositionPipeline=On}"
   Option         "TripleBuffer" "true"
   Option         "DynamicTwinView" "false"
   Option         "AddARGBGLXVisuals"
   SubSection     "Display"
       Depth       24
       Modes      "nvidia-auto-select"

conky indítása conky -bc ... (vagyis dupla puffer)

A conky fájlban magán belül 

    double_buffer = true,        -- nem villódzik az ablak - nem a fenét nem.
    text_buffer_size = 512,     -- szöveg puffer mérete

Az Nvidia grafikus beállítójában ki van pipálva az openGL szekcióban a Sync to Vblank.

Az asztali kezelőfelület a Plasma 5.15 Xorg meghajtóval.

Több ötletem nincs, de már fáj a fejem. Persze minek nekem conky, és megvan oldva. 
 

Sziasztok!

Zabbix-ban van egy monitorozott szolgaltatasom egy Ubuntu VM szerveren, ami hajlamos leallni, miutan lefutott az esti backup (Proxmox beepitett backup).

Mivel monitorozom ezt a szolgaltatast, arra gondoltam, hogy letrehozok egy actiont ha leallna.

Eloszor is a zabbix dockerben fut, uh letrehoztam egy olyan usert, aki belephet SSH-n a docker network IP tartomanyabol csak jelszoval erre a gepre (ami amugy a docker host is). Ez nyilvan azert kell mert alapbol SSH key is kene. Masodszor ennek a usernek root jogot adtam, hogy a (root-kent futo) szolgaltatast ujra tudja inditani. Harmadreszt bealliottam a sudoers fajlban, hogy ettol a usertol ne kerje el a jelszot ha sudo val inditok valamit.

Letrehoztam az actiont igy:

https://i.imgur.com/sSF5qTR.png

https://i.imgur.com/zlsH39G.png

A problema az, hogyha lealliom a szolgaltatast, nem inditja ujra... Az ertesites megjon zabbixbol hogy leallt, de ennyi.

Ha a docker IP tartomanyabol egy kontenerbol vissza SSH-zok a letrehozott userrel az Ubuntu-ra es futtatom a service ujrainditast, csont nelkul megcsinalja...

Nem tudom mi lehet a gond...

Sziasztok!

Tudtok a fentire valamilyen szép, szabványos és biztonságos megoldást?
Semmilyen többletjogosultságot nem szeretnék adni a NodeJS-es szolgáltatásnak, ezt leszámítva.