Debian GNU/Linux

Sziasztok. Régebben használtam a find parancsot arra, hogy speciális szöveget tartalmazó filet töröljön, úgy, hogy az útvonalon ahol keresem bizonyos mappák váltózóak.

Pl.:

/var/vmail/mx2.valami.hu/lab/Maildir/cur

/var/vmail/mx2.valami.hu/fas/Maildir/new

/var/vmail/mx2.valami.hu/naos/Maildir/cur

Vagyis itt lenne egy * a Maildir előtt, és 3db ? a Maildir után.

Régebben mintha ez nekem működött volna:

find /var/vmail/mx2.valami.hu/*/Maildir/??? -type f -mtime -2 -exec grep -l "direct.ro" {} \; -delete

Most viszont kiírja, hogy no such fil or directory. Az biztos, hogy a *-al és ?-elekkel van gondja, mert ha beillesztem a konkrét útvonalat, akkor megcsinálja.

Változott volna a find command?

Megoldás: Debian alatt nem a bash, hanem a dash az alapértelmezett, ezért a fenti parancsot be kell illeszteni egy bash -c "" közé.

Csináltam még anno egy scriptet, ahol menüből tudok választani, hogy az adott ssh-val mit szeretnék csinálni. Ennek része, hogy lehet olyat csinálni, hogy a megadott szervereken (ezt fzf-el oldom meg) lefuttat egy megadott parancsot. És itt szeretnék egy bonyolultabb sed parancsot kiadni, de az adott szerveren mikor tesztelem, akkor teljesen elkutyulja.

A parancs amit ha lokálisan kiadok, akkor működik:
sed 's/if \[ \$last_exit_code -ne 0 \]/if \[ \$last_exit_code -ne 0 \] \&\& \[ \$last_exit_code -ne 130 \]/g' .bashrc

Ez azt csinálja, hogy a if [ $last_exit_code -ne 0 ] -t lecseréli if [ $last_exit_code -ne 0 ] && [ $last_exit_code -ne 130 ] -ra

Gondoltam escape karaktert használok, hogy ne zavarodjon meg, de ez nem jött be, vagy rossz helyre teszem :) Hibakód nélkül lefut ssh remote parancsként futtatva, de több if [-el kezdődő parancsnál is lefut, és szétkutyulná a file-t.

vgrename volt, a vg1 mar nem letezik.

fstab-ban atirtam az uj utvonalakat. (systemctl daemon-reload is volt)

ujra generaltam az initramfs-t.

mit kell meg csinalni, hogy az update-grub mukodjon?

persze kezzel at tudom irni a grub konfigban es ujrainditani a gepet, de valami mas megoldas?

update:

ujrainditottam, jo lett, csak fura, hogy nem futott meg bele senki. :)

Sziasztok!

Keresnék egy debianban jártas, ispconfighoz értő szakembert aki segíteni tudna egy régi ispconfigot átmigrálni debian 12 alá. 

Sajnos a debian frissítés után 8 ról 12 re megdöglik az ispconfig,  és nem találtam megoldást,  hogy hogyan lehet életre kelteni illetve mi az oka. Ezért kellene átmigrálni a régi szervert ebben kellene segítség.

Köszönöm előre is.

Sziasztok. Debian 12-es alatt szeretnék beállítani SFTP-t, de számomra érthetetlen hibába futottam. Az alábbiakat csináltam eddig:

sudo groupadd sftpusers

sudo adduser csabacs

sudo usermod -G sftpusers csabacs

sudo micro /etc/ssh/sshd_config

Subsystem    sftp    internal-sftp

Match Group sftpusers
    X11Forwarding no
    AllowTcpForwarding no
    ChrootDirectory /srv/sftp/%u
    ForceCommand internal-sftp

sudo systemctl restart ssh.service

sudo mkdir -p /srv/sftp/csabacs

sudo chown csabacs:sftpusers /srv/sftp/csabacs/

Ezek után ha csatlakozni akarok, akkor hibaüzenetet kapok a logban:

sshd[3501140]: fatal: bad ownership or modes for chroot directory "/srv/sftp/csabacs"

Viszont, ha a csabacs mappa tulajdonjogát root:sftpusers -re módosítom, akkor lehet már csatlakozni, de semmit nem tud másolni a mappába. Ha 775-ös chmodot adok neki, hogy az sftpusers is tudja írni, akkor meg szintén nem csatlakozik, mert az se jó jog neki.

Hogyan lehetne beállítani rendesen, hogy az adott user csak a saját mappájába tudjon csatlakozni (ez lenne elvileg az sshd_configban a /srv/sftp/%u), és oda tudjon másolni fileokat, létrehozni könyvtárakat, meg törölni is onnan?

Megoldás: "a chroot konyvtar ala tegyel egy konyvtarat, ami a sajatja, akkor tudni fog bele irni"

nem tudja valaki, ez mitol lett? van ryzen 5600g-n es 9600x-n is

syslog:

kernel: [20107.052749] [drm] REG_WAIT timeout 1us * 100000 tries - optc1_wait_for_state line:817
kernel: [20107.056839] ------------[ cut here ]------------
kernel: [20107.056840] WARNING: CPU: 5 PID: 1927 at drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:7789 amdgpu_dm_atomic_commit_tail+0x31d5/0x36f0 [amdgpu]
[...]
kernel: [20107.057458] ---[ end trace 0000000000000000 ]---
kernel: [20107.855322] ------------[ cut here ]------------
kernel: [20107.855326] amdgpu 0000:0e:00.0: drm_WARN_ON(atomic_read(&vblank->refcount) == 0)
[...]
kernel: [20107.856348] ---[ end trace 0000000000000000 ]---

Xorg.0.log:

[123473.657] (EE) AMDGPU(0): drmmode_do_crtc_dpms cannot get last vblank counter

UPDATE:

6.1.0-26-amd64/6.1.112 ugy latszik mar nem jonnek ezek a hibak.

van revert is, es nagyon sok fix:

https://tracker.debian.org/news/1571620/accepted-linux-61112-1-source-i…

Adott egy linuxos imap szerver (dovecot + postfix) és még mindig probléma, hogy az iOS-es gyári mail app nem képes push notificationsre, mert csak az APN-t támogatja. Az pedig nem érhető el natívan Linux alatt.

Most azt olvastam, hogy a dovecot támogatja az imap_idle -t, ami már elég közel lenne a push notifications-hez, és csak engedélyezni kell a configban:

protocol imap {
    mail_plugins = $mail_plugins imap_idle
}

De ha ezt megteszem, és dovecot service restart, akkor látom, hogy gond van:

Error: Plugin 'imap_idle' not found from directory /usr/lib/dovecot/modules

Viszont ne látok infót, hogy ezt a plugint hogy lehet feltenni. Debian 12-őt használok.

Van valakinek infója, hogy ezt a plugint hogyan lehet feltenni Debian 12 alatt?

Van szép módja annak Ansible alatt, hogy ha egy playbookon belül több apt csomagtelepítés is van, és mindegyiknél be van állítva az update_cache paraméter, akkor csak az elsőnél hajtsa végre az apt update parancsot?

UPDATE1: Többetek szerint a túloldalt valamilyen módon blokkolva lehetünk, úgyhogy megpróbálok beszélni velük. Köszönöm mindenkinek a segítséget!

UPDATE2: Végre sikerült beszélni a "céggel", és az ip-t véletlenül blokkolták.

Belefutottam egy érdekes hibába. Adott egy iroda, amiben lokálisan van egy Debian 12-es szerver. Ez osztogatja az ipke-t a helyi hálón és a wifire csatlakozó Widows-os gépeknek, és raspberry pi-knek (ezek más hálón vannak).

Egyik partnerünk adott egy sftp-s hozzáférést a szerverükhöz, amire nem tudok csatlakozni (minden más partnerére, és a mi szervereinkre igen) egy Windows 11-es notival. Ha lecsatlakozok a helyi hálóról, és mobillal adok netet, akkor simán tudok csatlakozni. Ha a szerveren közvetlenül adom ki az ssh -vvvvA user@x.y.z.w -p 8822 -re, akkor az alábbiakat kapom:

OpenSSH_9.2p1 Debian-2+deb12u3, OpenSSL 3.0.13 30 Jan 2024
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/home/user/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/home/user/.ssh/known_hosts2'
debug3: ssh_connect_direct: entering
debug1: Connecting to x.y.z.w [x.y.z.w] port 8822.
debug3: set_sock_tos: set socket 3 IP_TOS 0x10
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_rsa type -1
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
debug1: identity file /home/user/.ssh/id_ecdsa type -1
debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/user/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/user/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/user/.ssh/id_ed25519 type -1
debug1: identity file /home/user/.ssh/id_ed25519-cert type -1
debug1: identity file /home/user/.ssh/id_ed25519_sk type -1
debug1: identity file /home/user/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/user/.ssh/id_xmss type -1
debug1: identity file /home/user/.ssh/id_xmss-cert type -1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u3
kex_exchange_identification: Connection closed by remote host
Connection closed by x.y.z.w port 8822

Vagyis kex_echange_identification problémája van. És bár a szerveren az ssh szerver configban vannak korlátozások erre vonatkozóan, de ott se a kliens oldali részben, amúgy meg a hálózaton levő összes Windows-os gépről sem lehet oda sftp-vel csatlakozni. A szerveren amúgy van nftables és fail2ban, de az nbftables loggolásakor sem látok olyat, hogy valamilyen forgalmat blokkolna.

Van bárkinek ötlete, hogy ez mitől lehet? :)

Sziasztok!

Ssd hiba miatt telepîtenem kell a napokban az asztali számítógép em.

Ki melyik szervert szokta használni?