Linux-haladó

Üdv, gyorsban összefoglalva,

adott egy régebbi dovecot szerver (annyira nem régi 2.2.X) amiről szeretném átmigrálni az összes user emailjét doveadm sync segítségével, mivel ugye így gyakorlatilag megmaradnak a GUID/subscription/egyéb dolgok is.

Eddig nincs is gondom, e szerint haladok: https://wiki.dovecot.org/Tools/Doveadm/Sync

Alap scriptek már elkészültek rá, masteruser használatban van, teljesen jól megy. Amit tudni a érdemes, a régi rendszer az "oldschool" linux userekre bontott történet, ez megy át most majd egy virtual*SQL cuccba, bár ez nem oszt nem szoroz elvileg.

A problémám nem is a migrálással van, mert a fenti példából összeeszkábáltam egy jó kis cuccost ami a következő:

doveadm -Dv -o imapc_user=$EMAILUSER -o imapc_password=XXXXX -o mail_fsync=never backup -1 -R -u $EMAILUSER@DOMAIN.hu imapc:

Ugye a dovecot WIKI szerint ez egy full backupot csinál az éppen aktuális állapotról a régi szerverről -> új szerverre. Szuper. Ezzel nincs is gond, attól eltekintve, hogy ez csak "üres" Maildir-be tud dolgozni, mert amúgy segfault és egyéb nyalánkásgok jönnek, ha van valami a destination oldalon, de ez nem is gond, mivel az új szerver töküres, mehet üres Maildirbe.

Oké, amikor ez megvolt, jöhetne az a kérdés, mivel sok levélről van szó, hogy hát sync-elni kellene.. ~10 napja eltelt változásokat, erre van a következő:

doveadm -Dv -o imapc_user=$EMAILUSER -o imapc_password=XXXXXX -o mail_fsync=never sync -1 -R -u $EMAILUSER@DOMAIN.hu imapc:

Ez szépen le is szedi az "új" leveleket, csak épp nem a változásokat.. pl ha a user átmozgatott egy rakás levelet egyik könyvtárból a másikba, azt bizony lesynceli mint "új" könyvtár. Igen, látom ott a -1 -es opció, hogy a remote oldalt még véletlenül se cseszegesse, de az nem véletlen van ott. Teszt fiókkal -1 nélkül sajnos futottam bele olyanba, hogy a régi szerveren is megváltoztak dolgok.. (teszt fiók volt szóval nem éles).

Van bármi egyéb opció, vagy ötlet erre, vagy ugorjak neki és menjen a sima backup a "nagy átállás" előtt és utána esetleg egy gyors sync rész ?

Valami olyasmit kerestem volna mint az rsync csak dovecot alá, de ugye ez így nem opció, a GUID / egyéb IMAP dolgokat pedig meg kell őríznem minden képpen, szóval az "átmásolám / átrsyncelem" fizikálisan a fiókot nem nagyon járható út szerintem, de fixme.

Vagy lehet én gondoltam túl és van erre egy sokkal egyszerűbb verzió is ... 

Előre is köszi! :)

Sziasztok,

szeretném lecserélni a jelenlegi mentési rendszereket.
Bareos-t használok három különböző rendszeren és nem vagyok vele elgedett, mert sok benne a bug és instabil.

Jellemzően 1-3 havonta készül full, 2-4 hetente differential, naponta incremantal.

A három jelenlegi megoldás:

1. AWS S3-ba ment, full-ok átkerülnek Glacier Deep Archive-ba.
   Nagyságrendileg 8TB amit mentek. Ez a legstabilabb, de időnként nem hajlandó létrehozni az új foldert a bucketban

2. Helyi diskre ment, naponta elmásolja az újonnan készült backupokat AWS S3-ba, onnan megy át szintén GDA-ba
    2-3TB amit mentek, itt is előjönnek pár hetente random hibák, elsősorban volume kezeléssel.

3. Helyi diskekre ment, hetente LTO5-re másol egy konszolidált mentést
    30TB körüli a méret

A hibákat a mentő service restartja megolja, tehát nem config hiba, de már belefáradtam a debuggolásba.

Erre keresek alternatívát.

A legigéretesebb a Restic backup, az időzítést Rundeck-kel oldanám meg. A 2. és 3. esetben egy helyi Minio serverre mentenék local esetén, az S3 nyilván eleve megoldott benne. A tape az ami kérdéses lehet, ott hetente kipakolnám tar-okba a hostok mentéseit a Minio-bol és a jó öreg Amandával írnám ki és kezelném a szalagokat, az atombiztos.

Ismertek olyan megoldást ami stabil és bevált?

Hello. Nemrég kaptam egy nagyon egzotikus feladatot, amiben egy már meglévő Exchange 2016 os rendszert szeretnének átemelni AD környezetből OpenLDAP ba biztonsági problémák miatt. Az egyik kollégám szerint megvalósítható a dolog, mert már csinált ilyet. Nekem viszont lövésem sincs, hogy ez mekkora szívás sorozatot vonzana magával, ha nem a saját vérével keresztezzük működés közben, ami előbb vagy utóbb úgy is bekövetkezik szokásosan. Konkrétan a googlet turkálom már egy ideje, használható leírások után, viszont nagyából egy darab értelmes sincs. Van ehhez valakinek valami használható anyaga esetleg? Mekkora szívás van a jövőben a frissítésekkel pl. cu, amikor varázsol az ad ban? Egyáltalán kivitelezhető ez a felállás? Köszönöm a tapasztalatokat, hátha más fejében is megfordul a jövőben ez a kérdés. 

Leírom a megoldandó problémát:

Van egy rendszerem: homeassistant, mqtt, zigbee2mqtt, zigbee (lámpa) a főbb komponensek.

A lámpát néha lekapcsolják (fizikai kapcsolóval teljesen áramtalanítódik ilyenkor). Értelemszerűen ekkor hiába küld neki bármilyen automatizálás bármit.

Azt szeretném elérni, hogy a kívánt állapot (kapcsolás, fényerő) tárolódjon el valahol és amikor a lámpa ismét elérhető akkor legyen beállítva jól.

Nem muszáj azonnal, ha cronjobból 5 percenként történik az is teljesen oké megoldás.

Üdv, egy érdekességgel találkoztam a mai nap.

Adott egy "tökegyszerű", tökáltalános setup:
postfix + sql (virtusers) + dovecot + imap + dovecot/lmtp deliver + fiókok... + előtte egy mailscanner (spammassassin szűréssel)

Ami az érdekesség, van egy Konica nyomtató, tökmind1, amiben scannelni szeretett volna a user, a saját mailboxjába.

A nyomtató egy xx@yy.com címről adja fel az üznetet a  helyi postfixos szervert használva, autholva, stb. ezzel nincs is gond, mert házon belül így megy már nekik vagy 4 éve ez az egész rendszer.

A címzett legyen user1@ . tárgy simán [SCAN] subject, body-ban semmi, + egy csatolt PDF. Ezzel azért nincs is gond, mert kb ~3 napja ez még ment simán.

És most, hogy kellően teleszemeteltem a bevezetést, rá is térhetünk a lényegre.

user1@ outlookjában (outlook + imap) látszódik, hogy jött egy üzenet, viszont fizikálisan nem látszik az outlook kliensben. Vonatkoztassunk el, webmail-en sem látszódik (úgy hogy outlook is be van zárva, stb).

Amit látok menet közben a logokban, postfix log -> minden rendben történik, a nyomtató beauthol, a mailscanner lescanneli, a címzések jók, statusban status=sent -et kapok.

Itt kezdődik az érdekesség.. postfix szerint rendben van minden, átment a spamszúrőn, lerakta a mailboxba. Igen. Lerakta. Mehet közben azt vettem észre, tesztelgetések során, hogy az outlookba megjelenik a [scan] email kb ~2 másodpercre és utána eltűnik teljesen az üzenet. De olyan szinten tűnik el, hogy fizikailag a szerveren sem találom fájl szinten sem.

Volt olyan teszt is, hogy néztem a 'cur' mappát CTRL+R -re rátenyerelve, hogy mi is történik a fizikai fájl lepakolása után. egyszerűen megjelenik egy 2másodpercre fizikálisan a fájl a jó helyen és utána paff eltűnik valahova..

dovecot_debug-ot bekapcsoltam, új teszteket végeztem... a dovecot_debug logban semmi nem utal arra, hogy bármi máshogy történne, mint másik beérkező levél esetén. Postfix log szintén zenész.

sieve szabályok nem játszanak ennél a usernél, mert az perpill ki van kapcsolva. Outlook saját belső szabályai nem játszanak, mert ha be van zárva az outlook, akkor is ugyan ez történik szerver szintjén.

Egy pillanatra odakerül a fájl és egy pillanat múlva már el is tűnt.. Ilyennel én még nem találkoztam, pedig nem ma kezdtem. Lehet valami triviális gond, lehet már belefutott valaki ilyenbe, ezért is kérdezem, hátha van valakinek ötlete, hogy ez WTF lehet.

Kis kiegészítés, ugyan ez a szkenneléses cucc, egy user2@ címre simán átmegy és nem tűnik el. Más levél simán beérkezik ... nem tűnik el.

Ötletek? :) Köszi előre is :)
 

ps.: a kliensek által okozott gondokat kizárnám, mert _minden_ kliens ki lett léptetve / be lett zárva / stb ami okozhat esetleg ilyesmit. + a logokban sem volt semmi olyanra utaló jel, hogy egy kliens belépett volna és intézkedett volna.

ps2.: ez egyik napról a másikra jelentkező probléma egy olyan rendszerben, ahol konfig területén ~2éve nem történt semmi féle fajta változtatás, se dovecot oldalon, se postfix oldalon, se a kliensek oldalán, se sehol.

[SOLVED].. btw, soha nem szabad elhinni az ügyfélnek amit mond .. (vagy legalábbis kezeljük fenntartásokkal...) egy otthoni laptop kliens okozta ezen problémákat.. amin volt szabály is arra a bizonyos üzenetre ami nem érkezett meg.. bár érdekes, mivel IMAP, nem szinkronizálódott le az a mappa, tippre IMAP mappán kívülre rakott mappáról van szó. Szóval solved.. de azért googliztam vele pár kört. Az hogy a logokba miért nem tűnt ez fel nekem, az passz, szerintem ez az a tipikus eset lesz, amikor nagyon keresel valamit, kiböki a szemed és mégse látod meg...  :)

Köszönet a hozzászólásokért / tippekért  mindenkinek! :)

Sziasztok!

Adott egy Zentyal 3.4.10-es mail szerverem, amin mail, illetve ftp szolgáltatás fut.

Mióta cseréltem benne a winchestereket WD RED 1TB (WD10EFRX) szeriara, azóta a biztonsági mentés, ami a 30gb+ méretű .tar filokat mozgat ki egy usb-s diskre, eltart akár 13 órán át is.

A probléma ugyanaz, ha NAS-ra mentem ki az adatokat, ami gigabites kapcsolaton van összeköttetésben a szerverrel.

Más fórumokon arra hivatkoztak, hogy az SMR technológia az oka, mert mc-vel, dd-vel is ugyanugy belassul a folyamat, ha külső tárolóra küldök adatot.

A végzett tesztek szerint viszont, a hdparm 130mb/s sebességet mond mind a két merevlemezre, ami egyébként sw raid1-ben van, ha ftp-el másolok a szerverre, vagy a szerverről, akkor ugyancsak megvan a 100-130 Mb/s sebesség, 40gb+ méretű file esetén is, szóval az smr problémát kizárnám.

Ha másolok egy 5gb méretű filet pl. a külső HDD-re, akkor ott 130Mb/s-ről lelassul 7mb/s-re a folyamat, majd miután próbálom vissszatenni a másolt adatot, akkor 500kb/s-ről kezdi a folyamatot, ami felmegy maximum 4mb/s-re.

Van erre szerintetek bármi megoldás, mert legtöbb fórumon annyit javasoltak, hogy cseréljem le a hdd-ket, illetve a zentyalt is, de jelen esetben egyik sem kivitelezhető hosszabb leállás nélkül.

Többi szerver, amit üzemeltetek ugyanilyen hdd-vel dolgozik, de nincs probléma egyikkel sem, és ezt a HDD-t sem láttam az SMR-es HDD-k listájában, így valami rendszer hibára gyanakszom, vagy esetleg paraméter hangolásra.

Köszönöm előre is a segítő hozzászólásokat!

Sziasztok.

Van egy BMS observium szerverünk amit szeretnénk ESXi -VM re költöztetni, ugyanakkor az alatta levő CentOS-t Ubuntu Server 20.04-re cserélni és a legújabb verzióra upgradelni. Megcsináltam a VM-et, felraktam scriptből a legújabb Observium comunity-t, kidumpoltam az adatbázist a régi serverből, becsomagoltam a rrd könyvtárat, átköltöztettem az új serverre, adatbázis vissza rrd átmásol, jogsúltságot beállítottam (átmásoltam a config.php-t is) és nem tudok beloginolni semmiféleképpen a web interface-n. A régi servernél ldap volt beállítva de hiába állítok bármi mást (mysql pl) csak visszaadja a login képernyőt hibaüzenet nélkül. Természetesen csináltam új usert az "adduser.php user pass 10" el. Egyedül a http-auth nál fogadja el a jelszót de újabb usert és jelszót kér rögtön ahol semmit nem fogad el, és dob egy unauthorized hibát. Hely van bőven a szerveren a logokban meg nem találok semmit. Az a fura hogy pár hete tesztkörnyezetben már lezongoráztam ezt és ment mindenféle varázslat nélkül, most meg semmiképp nem jutok előre.   

Van valakinek valami ötlete hogy mit tudnék leellenőrzini, vagy merre induljak el?

Hali, kerlek segitsetek megfejteni egy linux kernel mukodest. Szoval adott  a szitu, hogy NFS share nem elerheto, ezert force unmountra van szukseg. Viszont a force unmount szinten blockol, azaz van neki egy timeoutja (neha). Viszont azt tapasztalom, es a tapasztalatot kene valahogy bizonyitanom, hogy ha SIGKILL-et kuldok az umount-nak, akkor a signal utan eltunik a mount point.

# mount 192.168.3.104:/media/wd/data /mnt
# mount | grep nfs4
192.168.3.104:/media/wd/data on /mnt type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.3.102,local_lock=none,addr=192.168.3.104)

# # Turn off network

# strace umount -f /mnt &
[1] 443087
...
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7ff370ce6ad0) = 443091
wait4(443091,# # Umount is hanging

# ps x | grep umount
 443087 pts/0    S      0:00 strace umount -f /mnt
 443090 pts/0    S      0:00 umount -f /mnt
 443091 pts/0    D      0:00 /sbin/umount.nfs4 /mnt -f
 443271 pts/0    S+     0:00 grep --color=auto umount
# kill -9 443091

[{WIFSIGNALED(s) && WTERMSIG(s) == SIGKILL}], 0, NULL) = 443091
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=443091, si_uid=0, si_status=SIGKILL, si_utime=0, si_stime=0} ---
dup(1)                                  = 3
close(3)                                = 0
dup(2)                                  = 3
close(3)                                = 0
exit_group(-1)                          = ?
+++ exited with 255 +++
[1]+  Exit 255                strace umount -f /mnt

# mount | grep nfs4

# # Empty result

Szoval az latszik, hogy az umount nem csinal semmit a signal utan (se a /sbin/umount.nfs4 /mnt -f se a strace umount -f /mnt). A POSIX szabvany sem engedi az appoknak kezelni ezt a signalt. De valami megis eltunteti a mount pointot ?? Ha van otlet mit nezzek meg legyszi ne tartsd vissza. Koszi

Sziasztok!

Kínozza már valaki magát rootless dockerrel? Próbálom belőni, de az istennek sem..

Nem indul a konténer, ha magam alá tolok egy nagy adagot sem: sima "docker run -d -p 1080:80 nginx" után jön a:

docker: Error response from daemon: OCI runtime create failed: container_linux.go:367: starting container process caused: process_linux
.go:340: applying cgroup configuration for process caused: read unix @->/run/systemd/private: read: connection reset by peer: unknown"

##############################

Host: Debian 11 - 5.10 kernel, itt már default cgroup v2 van - clean install, semmi extra hegesztés

- iptables, uidmap, slirp4netns, fuse-overlay telepítve apt-tal.

##############################

Egy két konfigot megxcsináltam a rendszeren:

- br_netfilter kernel modul boot time betöltése

- cpu cpuset io memory pids - delegálása  (kevesebb is a warning a docker infoban tőle jóval) defaultban csak a memory és a pids van megadva.

##############################

A telepító script alapból ugye a saját runc-jét hozza, kínomban már felraktam apt-tal a tárolóbelit, majdan kicseréltem. Jelenleg "1.0.0~rc93+ds1-3" a verzió - same shit, de a hiba picit más

docker: Error response from daemon: OCI runtime create failed: container_linux.go:367: starting container process caused: process_linux.go:340: applying cgroup configuration for process caused: write unix @: sendmsg: broken pipe: unknown.

##############################

docker info

Client:
 Context:    default
 Debug Mode: false
 
Server:
 Containers: 1
  Running: 0
  Paused: 0
  Stopped: 1
 Images: 1
 Server Version: 20.10.6
 Storage Driver: fuse-overlayfs
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 05f951a3781f4f2c1911b05e61c160e9c30eaa8e
 runc version: 1.0.0~rc93+ds1-3
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
  rootless
  cgroupns
 Kernel Version: 5.10.0-6-amd64
 Operating System: Debian GNU/Linux 11 (bullseye)
 OSType: linux
 Architecture: x86_64
 CPUs: 3
 Total Memory: 3.839GiB
 Name: docker
 ID: 5TA3:NNDI:K577:AJCR:Q4KQ:QMP2:7J4Z:4PKI:F7BG:DCHJ:N6HD:H3SV
 Docker Root Dir: /home/<user>/.local/share/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false
 Product License: Community Engine
 
WARNING: No kernel memory limit support
WARNING: No oom kill disable support

##################################

Ötlet? valaki?

Sziasztok!

Jelenleg ubuntut használok. Egyre vackabb, és amúgy sem tetszik. Korábban használtam frugalware-t, mint-et és slackware-t.
Mit ajánlotok most, mi az ami egyszerűen használható, széles körűen támogatott és gyakran frissített?

Amire használom:
 - Virtuális gép - munkára,
 - Filmezés projektorral (optoma)
 - Hétköznapi otthoni használat (zene, doksik...)

Ubuntuból elegem lett. pl most azért mert a VGA kártyám csak waylanddal megy, ami egy (nekem) használhatatlan izé.