Linux-haladó

Sziasztok!
Alap Debian 9 telepítésnél amikor feltelepítem a MariaDB csomagokat "apt-get -y install mariadb-client mariadb-server" a következő hibaüzenetet kapom:

Setting up mariadb-server-10.1 (10.1.23-9+deb9u1) ...
Created symlink /etc/systemd/system/mysql.service → /lib/systemd/system/mariadb.service.
Created symlink /etc/systemd/system/mysqld.service → /lib/systemd/system/mariadb.service.
Created symlink /etc/systemd/system/multi-user.target.wants/mariadb.service → /lib/systemd/system/mariadb.service.
Job for mariadb.service failed because the control process exited with error code.
See "systemctl status mariadb.service" and "journalctl -xe" for details.
invoke-rc.d: initscript mysql, action "start" failed.
● mariadb.service - MariaDB database server
Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sat 2017-07-01 16:54:05 UTC; 23ms ago
Process: 1432 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=226/NAMESPACE)

Jul 01 16:54:05 vps systemd[1]: Starting MariaDB database server...
Jul 01 16:54:05 vps systemd[1432]: mariadb.service: Failed at step NAMESPACE spawning /usr/bin/install: Too many levels of symbolic links
Jul 01 16:54:05 vps systemd[1]: mariadb.service: Control process exited, code=exited status=226
Jul 01 16:54:05 vps systemd[1]: Failed to start MariaDB database server.
Jul 01 16:54:05 vps systemd[1]: mariadb.service: Unit entered failed state.
Jul 01 16:54:05 vps systemd[1]: mariadb.service: Failed with result 'exit-code'.
dpkg: error processing package mariadb-server-10.1 (--configure):
subprocess installed post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of mariadb-server:
mariadb-server depends on mariadb-server-10.1 (>= 10.1.23-9+deb9u1); however:
Package mariadb-server-10.1 is not configured yet.

dpkg: error processing package mariadb-server (--configure):
dependency problems - leaving unconfigured
Processing triggers for libc-bin (2.24-11+deb9u1) ...
Processing triggers for sgml-base (1.29) ...
Processing triggers for systemd (232-25) ...
Errors were encountered while processing:
mariadb-server-10.1
mariadb-server
E: Sub-process /usr/bin/dpkg returned an error code (1)

Van valakinek valami ötlete, nagy segítség lenne, próbáltam már pár tippet de sajnos sikertelenül, Köszi előre is.

Sziasztok. Anno készítettem egy jól összerakott bacula alapú mentő rendszert, amit most kezdtem el fejleszteni, s elmerülni a szépségeiben. A minap, hogy kijött a debian 9, szeretnék idővel több hasonló rendszert is beintegrálni a többi 6, 7, 8 as társához. Viszont valamiért a lentebbi Fatal error: Authorization key rejected by Storage daemon hibát kapok. A konfigok jól megvannak írva, azok nem dobnak vissza hibát, más mentések is ok. Viszont találtam egy ilyet a doksiban, ami egy kicsit zavaró. "Please also remember that File daemons with later versions than the Director and Storage daemons are not supported and can result in authorization errors." Nincs esetleg valakinek valami ötlete, hogyan lehetne megoldani ezt problémát? Köszi.

bacula-dir JobId 10987: Error: Bacula bacula-dir 5.2.6 (21Feb12):
Build OS: x86_64-pc-linux-gnu debian jessie/sid
JobId: 10987
Job: Wolfi-Web-Backup-Files.2017-06-30_16.50.42_08
Backup Level: Full
Client: "Wolfi-Web-FD" 7.4.4 (202Sep16) x86_64-pc-linux-gnu,debian,9.0
FileSet: "FileSet-Wolfi-Web" 2017-06-30 15:21:39
Pool: "Wolfi-Web-Full-Pool" (From Job FullPool override)
Catalog: "MyCatalog" (From Client resource)
Storage: "File" (From Job resource)
Scheduled time: 30-jún-2017 16:50:41
Start time: 30-jún-2017 16:50:44
End time: 30-jún-2017 16:50:56
Elapsed time: 12 secs
Priority: 10
FD Files Written: 0
SD Files Written: 0
FD Bytes Written: 0 (0 B)
SD Bytes Written: 0 (0 B)
Rate: 0.0 KB/s
Software Compression: None
VSS: no
Encryption: no
Accurate: no
Volume name(s):
Volume Session Id: 2095
Volume Session Time: 1493341786
Last Volume Bytes: 0 (0 B)
Non-fatal FD errors: 2
SD Errors: 0
FD termination status: Error
SD termination status: Waiting on FD
Termination: *** Backup Error ***

2017-06-30 17:06:26 Wolfi-Web-FD JobId 10987: Fatal error: Authorization key rejected by Storage daemon.
For help, please see http://www.bacula.org/rel-manual/en/problems/Bacula_Frequently_Asked_Qu…

Sziasztok!

Adott a címben szereplő UPS, ami rendelkezik UTP csatlakozással. Valahogy szeretném távolról monitorozhatóvá, menedzselhetővé tenni. A szépséghibája, hogy használt, a korábbi beállítások nem ismertek.

Kérdésem az lenne hogy ti hogyan vágnátok neki az IP cím kiderítésének?

Amit eddig próbáltam:
Laptoppal összekötöttem, laptopon beállítottam 10.0.0.1 IP címet, majd kiadtam egy 'ping -b 10.255.255.255' parancsot. Válasz nem jött rá, tcpdump kimenetében sem volt semmi. A műveletet megismételtem B és C címtartományban is. Az eredmény ugyanaz volt mindhárom esetben.

Segítségeteket és az esetleges ötleteket előre is köszönöm szépen!

RH 7.3-mal elvileg stabilnak jelölték a dolgot, de túl sok leírást nem találtam róla.

Használja ezt valaki? Sokkal lightosabb mint a régebbi clvm alapú dolog, RH is azt írja, hogy ez lesz a jövő.

Tisztelt Mindenki!

Sürgős segítség kellene egy négy lemezből álló tömb helyreállításához, aminek egyik lemeze meghalt, a rendszer (Debian 7) nem bootol.
A segítőt (nem ingyen) Veszprém környékéről várom. Kérem, jelentkezzen a személyes adatokban megadott címen!

Köszönöm!

Folyamatosan figyelünk arra, hogy a levelező szerverek ne küldjenek spam-et, ellenben szűrjék ki a fogadó oldalon.
Minden ügyfelünk aki hírlevelezni szeretne dedikált ip-t kap, legtöbbször dedikált szervert.
De a gmail folyamatosan szopat.... Be van állítva a domain SPF rekordja, be van állítva a google postamster tools-ban a domain, hogy ellenőrzött legyen, nincs spamlistán az ip/domain név... de neki a levelünk spam... s persze ehhez a retek szolgáltatóhoz se telefon se semmi... az ügyfél meg mit mond... de hát az a gmail...mintha etalon lenne...
Ti ilyenkor mit csináltok ?

Hellósztok,

Kipróbáltam egy teszt telepítésen ezt a Bluestore megoldást (Kraken-nel), és hát azt kell mondjam, elképesztő! Jóval gyorsabb mint a korábbi xfs/ext4 alapú megoldás (majd csinalok tesztet ugyaabba a virtuális gép clusterbe, hogy mennyi jön ki).

Ahogy látom az egész SSD journal dolgot átalakították, most van ez a block.wal és block.db. Nem igen találni még a neten ezekről sok infot, hogy érdemes itt most csinalni? Mehet mind a két block* egy SSD-ra (ha korábban SSD journal volt, gondolom ez áll legközelebb hozzá)?

A másik, hogy mikor lesz ez teljesen supportált, atomstabil dolog?

Sziasztok!

A gépemen Ubuntu 17.04 fut, de valamiért a geth --rpc --fast --cache=1024 parancs mindig kiakad corruption hibával.

CRIT [06-18|12:40:19] Failed to store block body err="leveldb/table: corruption on data-block (pos=782299): checksum mismatch, want=0xa404e904 got=0xbde0fb95 [file=003627.ldb]"

Szerintetek hardware gond, vagy maga a geth program hibás?

Amúgy más gondom nincs a PC-vel.

Sziasztok!

Az alábbi problémával állok szembe, viszont sehogy se tudok rájönni a hibára.
Van 4db Dell R510-es szerverünk, melyeken Debian 8 rendszer fut NFS szerverként megosztott BTRFS kötetekkel. Mind a 4 szerver esetén egy Perc H700 mögött vannak a diszkek RAID1-es kötetekben.

3 szerver esetén előjön az alábbi kernel bug, ezután pedig NFS-en keresztül szinte elérhetetlen lesz (egy sima metadata lekérdezés is másodpercekbe kerül), viszont lokálisan úgy ahogy eldöcög (habár ilyenkor is teljesen belassul):

[Mon Jun 5 12:13:45 2017] general protection fault: 0000 [#1] SMP
[Mon Jun 5 12:13:45 2017] Modules linked in: nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc ttm joydev drm_kms_helper drm iTCO_wdt coretemp i2c_algo_bit i2c_core kvm_intel dcdbas acpi_power_meter evdev serio_raw pcspkr iTCO_vendor_support kvm shpchp lpc_ich mfd_core tpm_tis button tpm i7core_edac edac_core processor thermal_sys loop ipmi_watchdog ipmi_si ipmi_poweroff ipmi_devintf ipmi_msghandler fuse autofs4 ext4 crc16 mbcache jbd2 btrfs xor raid6_pq hid_generic usbhid hid sg sd_mod crc_t10dif crct10dif_generic ses enclosure crct10dif_common crc32c_intel psmouse ehci_pci uhci_hcd ehci_hcd megaraid_sas usbcore usb_common scsi_mod bnx2
[Mon Jun 5 12:13:45 2017] CPU: 0 PID: 3902 Comm: nfsd Tainted: G I 3.16.0-4-amd64 #1 Debian 3.16.43-2
[Mon Jun 5 12:13:45 2017] Hardware name: Dell Inc. PowerEdge R510/0DPRKF, BIOS 1.2.12 04/07/2010
[Mon Jun 5 12:13:45 2017] task: ffff8803f9fccbe0 ti: ffff8803f38cc000 task.ti: ffff8803f38cc000
[Mon Jun 5 12:13:45 2017] RIP: 0010:[] [] __d_lookup+0x68/0x150
[Mon Jun 5 12:13:45 2017] RSP: 0018:ffff8803f38cfb70 EFLAGS: 00010202
[Mon Jun 5 12:13:45 2017] RAX: ffffc90000e01d48 RBX: 1d29b4080d2d8e40 RCX: 000000000000000b
[Mon Jun 5 12:13:45 2017] RDX: ffffc90000016000 RSI: ffff8803f38cfc30 RDI: ffff88027431e918
[Mon Jun 5 12:13:45 2017] RBP: ffff88027431e918 R08: 0000000000000000 R09: 0000000000000008
[Mon Jun 5 12:13:45 2017] R10: 0000000000000000 R11: 0000000000000003 R12: ffff8803f38cfc30
[Mon Jun 5 12:13:45 2017] R13: 0000000000000010 R14: 0000000010ea836a R15: ffff880421368258
[Mon Jun 5 12:13:45 2017] FS: 0000000000000000(0000) GS:ffff88042fc00000(0000) knlGS:0000000000000000
[Mon Jun 5 12:13:45 2017] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[Mon Jun 5 12:13:45 2017] CR2: 00007fa4dc621000 CR3: 0000000001813000 CR4: 00000000000007f0
[Mon Jun 5 12:13:45 2017] Stack:
[Mon Jun 5 12:13:45 2017] ffff880421368270 0000000000000000 000000000025efdc ffff8803f38cfc30
[Mon Jun 5 12:13:45 2017] ffff88027431e918 ffff8803f38cfc17 0000000000000000 ffff880421368258
[Mon Jun 5 12:13:45 2017] ffffffff811c2fe5 0000000000000000 ffff88027431e918 ffff8803f38cfc30
[Mon Jun 5 12:13:45 2017] Call Trace:
[Mon Jun 5 12:13:45 2017] [] ? d_lookup+0x25/0x40
[Mon Jun 5 12:13:45 2017] [] ? lookup_dcache+0x2b/0xc0
[Mon Jun 5 12:13:45 2017] [] ? __lookup_hash+0x1a/0x40
[Mon Jun 5 12:13:45 2017] [] ? lookup_one_len+0xcd/0x120
[Mon Jun 5 12:13:45 2017] [] ? nfsd4_encode_dirent+0xbe/0x3d0 [nfsd]
[Mon Jun 5 12:13:45 2017] [] ? nfsd4_encode_getattr+0x50/0x50 [nfsd]
[Mon Jun 5 12:13:45 2017] [] ? nfsd_readdir+0x19f/0x2a0 [nfsd]
[Mon Jun 5 12:13:45 2017] [] ? nfsd_direct_splice_actor+0x20/0x20 [nfsd]
[Mon Jun 5 12:13:45 2017] [] ? nfsd4_encode_readdir+0xee/0x200 [nfsd]
[Mon Jun 5 12:13:45 2017] [] ? nfsd4_encode_operation+0x75/0x190 [nfsd]
[Mon Jun 5 12:13:45 2017] [] ? nfsd4_proc_compound+0x24a/0x7e0 [nfsd]
[Mon Jun 5 12:13:45 2017] [] ? nfsd_dispatch+0xb2/0x200 [nfsd]
[Mon Jun 5 12:13:45 2017] [] ? svc_process_common+0x451/0x6e0 [sunrpc]
[Mon Jun 5 12:13:45 2017] [] ? nfsd_destroy+0x70/0x70 [nfsd]
[Mon Jun 5 12:13:45 2017] [] ? svc_process+0x10c/0x160 [sunrpc]
[Mon Jun 5 12:13:45 2017] [] ? nfsd+0xbf/0x130 [nfsd]
[Mon Jun 5 12:13:45 2017] [] ? kthread+0xbd/0xe0
[Mon Jun 5 12:13:45 2017] [] ? kthread_create_on_node+0x180/0x180
[Mon Jun 5 12:13:45 2017] [] ? ret_from_fork+0x58/0x90
[Mon Jun 5 12:13:45 2017] [] ? kthread_create_on_node+0x180/0x180
[Mon Jun 5 12:13:45 2017] Code: 48 c1 e8 06 44 01 f0 69 c0 01 00 37 9e d3 e8 48 8d 04 c2 48 8b 18 48 83 e3 fe 75 0f eb 35 0f 1f 44 00 00 48 8b 1b 48 85 db 74 28 <44> 39 73 18 75 f2 4c 8d 7b 50 4c 89 ff e8 46 70 35 00 48 39 6b
[Mon Jun 5 12:13:45 2017] RIP [] __d_lookup+0x68/0x150
[Mon Jun 5 12:13:45 2017] RSP
[Mon Jun 5 12:13:45 2017] ---[ end trace f84a1b4e02c5b855 ]---


Eddig arra gyanakodtam, hogy a "rossz" szerverek esetén Debian Wheezy volt, a "jón" pedig Jessie, viszont az upgrade nem oldotta meg a problémát.

Amit még észrevettem, az a kernel verzió:

• Jó esetén: 3.16.7-ckt25-2+deb8u3
• Rosszak esetén most: 3.16.43-2

S most nem igazán tudom eldönteni, mi okozhatja ezt a problémát. Ami kiválthatta az egészet, az az, hogy pár hete elkezdtünk rajta lokálisan számolni foglaltságokat (eddig NFS-es megosztáson keresztül ment), azaz lokálisan a gépekre helyeztük ezt át (megzavarta volna a BTRFS cache lelki világát?).

A btrfs-tools verziószáma 3.17.

Nem tudom, hogy egy jessie-backoprts-os kernel image mennyit javítana a helyzeten, de minden észrevételt, kérdést, bármi egyebet szívesen fogadok.

Sziasztok

adott egy server, benne 24 JBOD diszk, amit összefogok egy Volume Group-ba (VG)
ezen a VG-n létrehozok N db raid5 LV-t 5 stripe-on (4+1)

ha kihúzok egy diszket (amin volt egy stripe) akkor, hogyan tudom újraépíteni és áttenni egy másik diszkre azt az elhullot stripe-ot?

megjegyzés: ha lehet lvm-el szeretném megoldani és nem mdadm-al.

parancsok:

pvcreate /dev/sd{b..y}
vgcreate vg_data /dev/sd{b..y}
for i in {01..10} ; do lvcreate vg_data --type raid5 -i 5 -L 10G -n tgtdisk$i; done

ezzel nézem meg meg a stripeokat/hogy merre vannak:

lvs -a -o +devices -P


tehát a kérdés:
amíg megérkezik az új diszk, elkerülendő az adatvesztés, szeretném ha a kiesett diszken lévő stripe-ot egy másik diszken újra előállítaná a meglévőkből, hogyan? miként lehet megtenni?

Köszönöm előre is a válaszokat.