UNIX haladó

Van egy PC-m, amin Ubuntu fut. Az ubuntu egy SSD-re van telepítve. Mivel az SSD kapacitása kicsi, ezért a /home könyvtár tartalma egy régi HDD-n van.
Ez eddig oké, de lesz itthon egy saját építésű home server, aminek a kapacitása jóval nagyobb lesz, mint a régi HDD-m kapacitása. Arra gondoltam, hogy a /home tartalmát cakk-pakk átteszem a NAS-ra mondjuk (valahogy) seafile-on keresztül, és aztán beállítom az fstab-ban hogy webdav fájlrendszerként csatolja fel.

Tudom, talán egyszerűbb lenne NFS-el megoldani, de azért megpróbálnám a webdav-ot munkára fogni ha lehet.
- Az ok: tetszik a mostani telefonos webdav kliensem. :)

Problémák amik felmerülnek:
- Nem tudom, a webdavon keresztül, mennyire kezelhetők a linuxos userek, csoportok, jogok?
- Valszeg lassabb lesz mint a régi HDD-m.

A kérdésem az lenne, van e tapasztalat a fenti témával kapcsoltban? Vagy teljesen életképtelen ötletet találtam ki?

Sziasztok!

Van valami jól bevált megoldásotok egy még működő, de rengeteg bad sectorral rendelkező HDD lementésére?
Amit próbáltam:
Clonezilla -rescue kapcsolóval. kb 1% után kilépett.
Testdisk rettentően belassul. 100MB kb 1 óra.

Jó lenne megmenteni az adatokat, de ha csak egy része sikerül, az sem tragédia(Nem érzékeny adatokat tartalmaz, fotók, videók stb...).

Köszönöm!

Sziasztok!

Van egy konkrét (elméleti) feladatra van megoldási javaslatom, csak nem tudom, hogy van-e logikusabb, jobb vagy nyilvánvalóbb erre.

Adott 4 gép. Mind a 4 azonos szerver teremben lenne, azonos switch-re kötve. Mind a 4 gépben van 2 hálózati kártya. A 2-2 gép párban össze lenne kötve. A párban összekötött gépeken DRBD, aktív/passzív üzemmódban. Az aktív gépen működnek a szolgáltatások (web szerver, levelezés, stb), a passzív gép pedig csak szinkronizál. Failover esetén a passzív gép átveszi az aktív gép szerepét, és elindítja a szolgáltatásokat.
Itt most a kérdés, az IP címek.
Ha VIP-ként, virtuális IP címként lenne kezelve a páronként 1-1 IP cím, az tökéletesen működhet? Tehát az aktívé a publikus IP, majd ha történik valami ezzel az aktív szerverrel, akkor a passzív veszi át a publikus IP címét.

Ilyen átvételnél a szerver fingerprint változik. Ez elkerülhető, vagy van értelme, hogy elkerülhető legyen?

A 4 gép azért is jó, mert egy subnetben lesznek és bármelyik publikusról el tudom majd érni a nem publikus IP-vel rendelkező gépeket.

A passzív gépet pedig az aktív gépről SSH hozzáférésről érném el.

A kérdésem, hogy ez így OK? Van más ésszerűbb megoldás erre?

Milyen alternatív megoldások vannak erre? Tehát hogy a 4 gépből egyszerre csak 2-nek van publikus IP-je, a másik 1-1 gép pedig tartalék gép.

Köszönöm előre is a véleményed... :-)

KaTT

http://www.kutukupret.com/2011/06/19/postfix-realtime-maildir-replicati…

Ebben a cikkben leírt megoldás működőképesnek tűnik, a lényeg:

Így néz ki: http://www.kutukupret.com/wp-content/uploads/2011/06/Postfix-drbd-ocfs2…

- Lesz 2 elsődleges cluster fs (OCFS2) + DRBD, így mindkét szerverről írható a fájl rendszer. A fájlok így megoldva.
- Lesz aktív/passzív DRBD + XFS. A fájlok így megoldva.

Szolgáltatás: mindkettőn megy a Postfix. Erre én is gondoltam eddig, csak nem tudtam, a DNS MX rekordok hogy lesznek lekezelve, hát így:
Szolgáltatás: az aktívon megy a Postfix majd:

DNS szerveren:

example.com. MX 10 postfix1.example.com.
example.com. MX 10 postfix2.example.com.
postfix1 IN A 202.xxx.xxx.1
postfix1 IN A 202.xxx.xxx.2

Én még nem láttam azonos MX 10 MX 10 beállítást, általában 1 MX van, vagy ha kettő, akkor MX 10 és a backup-nak MX 20, ami tárolja a leveleket, amíg nem elérhető az elsődleges.

Ebben a cikkben közös MySQL szerver javasolnak, azonban ha lenne 3 node-os MariaDB Galera Cluster, akkor jól gondolom, hogy meg lenne oldva az adatbázis redundancia is?

Tehát a 3 szerverből kettőn lenne postfix, közöttük DRBD + OCFS2 (primary-primary) köztük DRBD+XFS aktív/passzív üzemmódban, de a postfix csak az aktívon futna, és a 3 node-os Galera Cluster-t használom, akkor ha az egyik postfix-es gép kiesik, akkor 100%-ban működik a levelezés tovább. Ha visszajön a kiesett gép, akkor szinkronizálódik a Cluster FS DRBD+XFS és a Galera adatbázis is.

Így működhet? Csinált valaki ilyet? Milyen elvi hibát vétettem?
CentOS 6 7 alapon akarom ezt összerakni.

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

UPDATE 1:

- Lesz aktív/passzív DRBD + XFS. Tényleg nem akarom magamat szívatni, csak ha tényleg indokolt... :-)
- CentOS 7

Sziasztok!

Kifogott rajtam a dolog, nincs ötletem. Ha tudtok segítsetek.

Adott egy debian szerverekkel megrakott (T-online szervertermi) belső háló ahol némely gépen kb. 1/3-ad arányban leidőzít a névfeloldás a 84.2.46.1 ip-t kérdezve.
Ugyanezen a gépen a másik (84.2.44.1) ns lekérdezés tökéletesen működik. A tűzfal külső hálókártyáját tcpdumpolva látszik hogy a kérés (-ek) kimennek, de válasz nem érkezik rá.

Ahogy gondolkodtam:
Csomagveszés nem lehet, mert egyrészt az egyik ns mindig jó, másrészt ha a lekérdezéshez tartozó első próbálkozás sikertelen akkor a másik kettő is az lesz kivétel nélkül.
Tűzfal probléma nem lehet, mert a külső oldalon sem látszik a válasz és a másik ns jól működik. A rc.firewall nem különböztet meg névszervereket.
Nem hinném hogy a 84.2.46.1 ns valami módon korlátozna minket, ha már a másik nem.

Szóval ez van.

udv,

1404 Lubuntu telepites.
lxsession elindul, szepen beallitottam.
azt szeretnem, ha a ~/.config/pcmanfm/lubuntu/desktop-items-0.conf csak olvashato lenne
de barmit csinalok, allandoan vissza allaitja a jogokat rw-rw-r--
meg akkor is, ha a root a tulajdonos.
mezei user desktopja, nem sudos, megis viszakerul a tulajdonaba a file.

hogyan lehetne ezt megakadalyozni ?

a cel az lenne, hogy a paraszt ne tudja elbarmolni a desktopot. egy ikon kinnt van az asztalon azt elinditja, ennyi kell.

Halihow,

egy (számomra) kemény dió feltörésében kérném nagyrabecsült közreműködéseteket.
:)

Egy olyan fájl-transzfert kellene összeraknom, ami külső és belső szolgáltatások között csücsül a DMZ-ben és a szolgáltatások közti fájlcserét biztosítja úgy, hogy:
1. a kommunikáció titkosított (kizárólag SSH/SFTP!!),
2. a fájlok tárolása titkosított,
3. a fájlokhoz titkosítatlan formában nem fér hozzá az illetékeseken kívül senki (root se),
4. csak egyszeres hitelesítés (kizárólag ssh kulcs!!) van,
5. egy transzfer tárolóhoz több júzernek kell hozzáférnie (pl. egyik feltölt valamit, a másik letölti ugyanazt).

Jelszó használatával sikerült készre csinálni a szervert (pam-encfs/pam-script használatával), de az ssh kulccsal jelenleg nem tudok megbirkózni (sftp kapcsolat nem tud jelszót "beírni"). Próbáltam a CrushFTP-t is, ami első ránézésre mindent tud, de a gpg kulcs helyi tárolása megborítja a 3. pontot.

Én szeretném ezt Linux alatt megvalósítani, de bármilyen más OS-re és bármilyen sw környezetre vonatkozó ötletet szívesen látok, tényleg!!!

üdv.,
g

update: a saját tapasztalatom és a lenti hozzászólások alapján ez a kérés megoldhatatlannak tűnik, köszönöm a hozzászólásokat!

Üdv,

Ubuntu 14.04 nem hajlandó rebootolni:

uname -a
Linux neutrino 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

A reboot folyamat megakad a Stopping system V runlevel compatibility [OK] után és az alábbi hibaüzenetet dobja:

Hibaüzenet:
[INFO]task systemd-udevd:1596 blocked more than 120 seconds
Not tainted 3.13.0-24-generic #47-Ubuntu

Mit tudok tenni, mi lehet a gond?

Előre is köszönöm

Sziasztok,

Van otletetek arra, hogy ha egy subshellben hatterben futtatok egy parancsot, hogyan szerezzem vissza enter leutese nelkul a promptot?

pl: ( ls & )

Elore is koszi a valaszokat.

cU

szeretnem a kozponti LDAP szerverunket lokalisan cachelni a kovetkezo feltetelekkel:

- tudjak lokalis overlayt rakni ra (pl posixAccountot egy olyan bejegyzesre, amin alapbol nincs)
- tudjak lokalisan entryket felvenni (pl csoportokat helyileg kezelni)
- a filtereket pass-throughban szeretnem latni, nem tudom lehuzni az egesz LDAP szervert, hogy utana filterezzek (translucent kiesett)
- a felhasznalok anonymous-binddel authentikalnak, azaz amikor user1@example.com be akar lepni, akkor elobb egy attributum=user1@example.com
keresesbol ki lesz szedve a DN, majd azzal + a felhasznalo jelszavaval bindel (sok cucc itt verzik el...)
- a hashekhez nem ferek hozza, csak read-only hozzaferesem van a globalis LDAP cimtarhoz

openldap+translucenttel probalkozott a kollega, de a filtereket csak lokalisan ertekelni ki, ami nekunk nem jo (tul sok rekordunk van a globalis LDAPban).

egyeb otlet?