Linux-haladó

Sziasztok!
Adott egy (virtuális) ubuntu server, benne eth0, és eth1. A két interfész két külön subnetben van, valamiért azonban csak az egyik interfészt tudom pingelni, a másik nem reagál.
tcpdump-pal megnéztem, és maga az int. megkapja a csomagokat, csak nem válaszol.
Próbáltam a /proc/sys/net/ipv4/ip_forwardot, és az rp_filtert is piszkálni, de egyik sem hatotta meg.

Szerintetek mi lehet a probléma?

en@serverem:# ifconfig
eth0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
inet addr:10.0.0.2 Bcast:10.0.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1690267 errors:0 dropped:0 overruns:0 frame:0
TX packets:1529337 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:147775750 (147.7 MB) TX bytes:223668668 (223.6 MB)

eth1 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
inet addr:10.0.1.2 Bcast:10.0.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1820704 errors:0 dropped:0 overruns:0 frame:0
TX packets:70 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1155387997 (1.1 GB) TX bytes:4244 (4.2 KB)

en@serverem:# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
localnet * 255.255.255.0 U 0 0 0 eth0
10.0.1.0 * 255.255.255.0 U 0 0 0 eth1
default 10.0.0.1 0.0.0.0 UG 100 0 0 eth0

Üdv:

sLamma

agyaltam a témán és szeretnék egy 286 linux retró glépet létrehozni!

Adott egy debian linux file server samba-val:

minden felhasználónak van egy home alkönyvtára:
4227073 drwxrwx--- 2 root user1 4096 maj 4 12.45 user1

illetve különböző megosztások sgid beállítással:
25845761 drwxrwsr-x 3 root muszak 4096 maj 19 10.42 muszak

létrehozok egy home alkönyvtáron belül egy symlinket ami a megosztásra mutat:
3301379 lrwxrwxrwx 1 root root 14 maj 14 11.45 muszak -> /share/muszak

S most jön a problémám amiben a segítségeteket kérném:
Ha a samba-n keresztül egy windows-os géppel közvetlenül belépek a /share/muszak megosztásba tökéletesen működik az sgid beállítás, azaz a megfelelő csoport kapja a bemásolt fájlnál a jogosultságokat:
25845761 drwxrwsr-x 2 root muszak 4096 maj 19 11.03 .
2 drwxr-xr-x 14 root root 4096 maj 19 10.56 ..
25845762 -rwxrw-r-- 1 root muszak 12732 febr 17 12.09 test.jpg

Ha viszont a samba-n keresztül egy windows-os géppel a home-ba lépek be és az ott található symlinken keresztül lépek be a /share/muszak megosztásba akkor nem működik az sgid beállítás, azaz már nem a symlink végén lévő könyvtár jogosultságok öröklődnek:
25845761 drwxrwsr-x 2 root muszak 4096 maj 19 11.07 .
2 drwxr-xr-x 14 root root 4096 maj 19 10.56 ..
25845762 -rwx------ 1 user1 muszak 12732 febr 17 12.09 test.jpg

Kerestem google-n megoldást de nem találtam, illetve nem vagyok biztos benne, hogy ez most samba symlink sgid vagy debian probléma...

sziasztok!

fog-ot használok bizonyos gépek klónozására és az utóbbi időben felmerült egy (természetesen szándékoltváltoztatás nélkül!) érdekes jelenség. 20 üres slot mellett előáll az, hogy csak egyet hajlandó csinálni, a többi várakozik a sorban. a kérdéses várakozók bebootolnak, majd azon a ponton, ahol a fog kernelt töltik be tftp-ről, ott várakoznak, de nem tudom mire. elkezd "pöttyözni", majd amikor a másik "deploy" véget ér, akkor betölti és indul, ismét csak egyet egyszerre.

elvileg a fog képes lenne indítani a dolgot több gépen (mármint nem multicast-ra gondolok persze), de valamiért a kernel betöltése várakozik. van valami ötletetek, hogy miképp lehetne rávenni, hogy induljon tovább? vagy mégis csak valahol a fog a ludas? azért gondolom, hogy nem, mert a gép "alatta frissül", de a fog maga nem.

sziasztok!

Segítséget szeretnék kérni tőletek abban, hogyan tudnám még gyorsítani a mysql adatbázist.
Szerver: dell poweredge sc1430 (cpu: 1db intel xeon e5310 quad core, 6GB ram, 2*250 hdd)
os: ubuntu linux 8.04 LTS
Innodb és myisam táblák is vannak. De főként innodb.
jelenlegi my.cnf:

[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock


[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
nice = 0

[mysqld]

user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
character-set-server = latin2
collation-server = latin2_hungarian_ci
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
language = /usr/share/mysql/english
skip-external-locking

key_buffer = 256M
max_allowed_packet = 16M
thread_stack = 128K
thread_cache_size = 8
table_cache = 512

query_cache_limit = 8M
query_cache_size = 256M

log_slow_queries = /var/log/mysql/mysql-slow.log

expire_logs_days = 10
max_binlog_size = 100M

skip-bdb

innodb_buffer_pool_size = 1G

[mysqldump]
quick
quote-names
max_allowed_packet = 16M

[mysql]

[isamchk]
key_buffer = 16M

!includedir /etc/mysql/conf.d/

Üdv!

Van egy igen nagy problémám.

A helyzet a következő. Van egy gép (R, 172.21.35.200), ami reverse proxyzik egy másik gépre (B, 172.21.22.216). Néhány egyszerű dolog van benne definiálva, pl.:

ProxyPass /certificates https://172.21.22.216/certificates
ProxyPassReverse /certificates https://172.21.22.216/certificates
ProxyPass /common https://172.21.22.216/common
ProxyPassReverse /common https://172.21.22.216/common
ProxyPass /derek https://172.21.22.216/derek
ProxyPassReverse /derek https://172.21.22.216/derek

.

Ez szépen is működik, minden https- en zajlik,

:80

nem nagyon játszik.

Van egy kliens program, amivel szeretném elérni (B), de (R)- en keresztül. Ha a desktopomról (D) elindítok egy kérést, pl.

 https://172.21.35.200/derek 

, az szépen landol is (D)- n. Na most eddig ok, de a kliens program használna tanusítványokat is, de az ilyen kérésekből már egy byte sem jut el (B)- hez. (R) logjában ezt találom:

[Tue May 18 12:33:11 2010] [info] [client 172.21.21.61] Connection to child 65 established (server 127.0.1.1:443)
[Tue May 18 12:33:11 2010] [info] Seeding PRNG with 648 bytes of entropy
[Tue May 18 12:33:11 2010] [debug] ssl_engine_kernel.c(1861): OpenSSL: Handshake: start
[Tue May 18 12:33:11 2010] [debug] ssl_engine_kernel.c(1869): OpenSSL: Loop: before/accept initialization
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1873): OpenSSL: read 11/11 bytes from BIO#b76c5f80 [mem: b76cb770] (BIO dump follows)
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1806): +-------------------------------------------------------------------------+
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1845): | 0000: 16 03 00 00 52 01 00 00-4e 03                    ....R...N.       |
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1849): | 0011 - <SPACES/NULS>
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1851): +-------------------------------------------------------------------------+
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1873): OpenSSL: read 76/76 bytes from BIO#b76c5f80 [mem: b76cb77b] (BIO dump follows)
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1806): +-------------------------------------------------------------------------+
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1845): | 0000: 4b f2 5e 6a d1 37 94 73-55 2e 4f a1 fc 2e 54 ea  K.^j.7.sU.O...T. |
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1845): | 0010: b6 eb a2 c3 f2 d7 11 d5-56 74 08 85 3e b4 d6 63  ........Vt..>..c |
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1845): | 0020: 00 00 26 00 39 00 38 00-35 00 16 00 13 00 0a 00  ..&.9.8.5....... |
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1845): | 0030: 33 00 32 00 2f 00 05 00-04 00 15 00 12 00 09 00  3.2./........... |
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1845): | 0040: 14 00 11 00 08 00 06 00-03 02 01                 ...........      |
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1849): | 0076 - <SPACES/NULS>
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1851): +-------------------------------------------------------------------------+
[Tue May 18 12:33:11 2010] [debug] ssl_engine_kernel.c(1869): OpenSSL: Loop: SSLv3 read client hello A
[Tue May 18 12:33:11 2010] [debug] ssl_engine_kernel.c(1869): OpenSSL: Loop: SSLv3 write server hello A
[Tue May 18 12:33:11 2010] [debug] ssl_engine_kernel.c(1869): OpenSSL: Loop: SSLv3 write certificate A
[Tue May 18 12:33:11 2010] [debug] ssl_engine_kernel.c(1269): [client 172.21.21.61] handing out temporary 1024 bit DH key
[Tue May 18 12:33:11 2010] [debug] ssl_engine_kernel.c(1869): OpenSSL: Loop: SSLv3 write key exchange A
[Tue May 18 12:33:11 2010] [debug] ssl_engine_kernel.c(1869): OpenSSL: Loop: SSLv3 write server done A
[Tue May 18 12:33:11 2010] [debug] ssl_engine_kernel.c(1869): OpenSSL: Loop: SSLv3 flush data
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1873): OpenSSL: read 5/5 bytes from BIO#b76c5f80 [mem: b76cb770] (BIO dump follows)
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1806): +-------------------------------------------------------------------------+
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1845): | 0000: 15 03 00 00 02                                   .....            |
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1851): +-------------------------------------------------------------------------+
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1873): OpenSSL: read 2/2 bytes from BIO#b76c5f80 [mem: b76cb775] (BIO dump follows)
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1806): +-------------------------------------------------------------------------+
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1845): | 0000: 02 2a                                            .*               |
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1851): +-------------------------------------------------------------------------+
[Tue May 18 12:33:11 2010] [debug] ssl_engine_kernel.c(1874): OpenSSL: Read: SSLv3 read client certificate A
[Tue May 18 12:33:11 2010] [debug] ssl_engine_kernel.c(1893): OpenSSL: Exit: failed in SSLv3 read client certificate A
[Tue May 18 12:33:11 2010] [info] [client 172.21.21.61] SSL library error 1 in handshake (server 127.0.1.1:443)
[Tue May 18 12:33:11 2010] [info] SSL Library Error: 336151570 error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate Subject CN in certificate not server name or identical to CA!?
[Tue May 18 12:33:11 2010] [info] [client 172.21.21.61] Connection closed to child 65 with abortive shutdown (server 127.0.1.1:443)

.

Van valakinek bármi ötlete, hogy ezt a problémát hogyan lehetne feloldani? Tényleg bármilyen megoldás érdekel, akár az is, hogy az apache2- t másra cseréljük. Az egyetlen, ami nem játszik, az az, hogy a portot forwardoljuk, pedig ez elég egyszerű lenne.

Az volt az elképzelésem, hogy A szerver backupjait B szerverre mentem. Ehhez B szerver VPN kapcsolatot létesít A szerverre, majd rdiff-backuppal letölti a fájlokat.
Ehhez legeneráltam a megfelelő RSA kulcsot, és megcsináltam az .ssh/config fájlt, ehhez hasonló módon:
https://unixlinux.tmit.bme.hu/Rdiff-backup#Backup-scriptek
A leírásban több hiba is van, az egyik, hogy a cron-ból futtatva nem működik a su parancs. Ezért ezt sudo-val váltottam ki. A másik, hogy ha sima felhasználóként fut az rdiff-backup, akkor nagyon sok állományhoz nem fér hozzá.
Rootként meg nem megengedhető az SSH.
És akkor itt most nem világos az elv:
vagy a B szerverről indítom root ként az rdiff-backupot, és akkor le tudok menteni mindent, bár elég kockázatos módon...
Vagy a B szerveren sima felhasználóként indítom a programot, és az A szerveren futtatja azt root jogokkal.

Hogy is van ez?

Sziasztok!

Abba a feladatba ütköztem, hogy hardeningelnem kell HP-UX-ot, redhat alapú linuxokat, és Suse linuxokat.

Kellene gyártanom tegnapra egy doksit, ami egy hardening rendszerterv lenne és szükséges lenne alapirányelveket lerögzíteni a doksiban. Esetleg van valakinek olyan anyaga, ami leírja az általánosan minden esetre érvényes hardening irányvonalakat, azaz mint mankó segít nekem elindulni? Nehezen fogom tudni összeszedni kútfőből értelmesen és logikusan azt a sok részletet, ami kell egy ilyen doksiba, és megvalósíthatónak is kell, hoyg legyen a későbbiekben. Szóval egy vonalvezető összegző, összeszedő vázlatdoksi alapelvekkel az igényem... Tudom, most ez alatt aztán mindent lehet érteni és nem pontos definiciókat írtam ide, de nem is konkrétumokról fog szólni ez a doksi. Az egy megvalósítási kézikönyv lesz, amit majd nyárra kell megírnom és elvégeznem.

Köszi előre is az erőfeszítéseket Üdv.: Balu

Tanácsot szeretnék kérni, hogy ezeket az újfajta (4k) HDD-ket, hogyan is célszerű kezelni.

- Hogyan/mivel érdemes formázni?
- A Bootolást mennyire befolyásolja, ha 63 helyett 64 szerkor van fenntartva, hogy a partíció 8-al osztható szertorszámra essen (ne legyen átlapolódás)?
- Az írási teljesítményben valóban drasztikus különbségek vannak, attól függően, hogy hogyan particionálom?
- Ha már rosszul lett particionálva a disk és teli van adatokkal, ez hogyan korrigálható?
- Kernel szinten van erre valamilyen támogatás, ha van melyiktől kezdve és mi ennek a funkciónak a neve?

Hirtelen ennyi jutott eszembe, de szívesen látok bármilyen egyéb kérdést/észrevételt is.

Előre is köszi

No igen, ilyenkor tudnék ölni... (csak képletesen)

Adott az udev nevű csoda, és a hálókártyáim.
Az a lényeg, hogy szeretném, ha újraindításonként ugyanúgy hívnák a hálózati kártyáimat, és lehetőleg úgy, ahogy én szeretném.
Erre találták ki az /etc/udev/rules.d/70-persistent-net.rules nevű állományt.
Ide bele is kerül a pár hálókártyám, két Intel gigabites kártya, és egy NVidia-s alaplapi gigabit kártya.
Ezek után megszerkesztem a .rules fájlt, hogy az alaplapi legyen az eth0, és a két intel-es kártya legyen az eth1 és eth2.
Reboot után pedig mit látok? A fájl üres, csak a wifi kártya bejegyzése van benne, ami az előzőekben nem volt benne...
No, most akkor miért is "persistent", ha mindig elfelejti?

Ja, igen. OS: Slackware64 13.0