Linux-haladó

Sziasztok!

Régebben (2001 környékén) villám gyorsan, kb 2-3 másodperc alatt töltődott be a 2.4-es kernel az akkori múzeális gépemen.
Egy saját fordítású 2.6-os kernel egy 1,8ghz-es Pentium M processzorral viszont kész türelempróba. Szépen végig lehet nézni, hogy a kernel betöltésekor hogyan pingálja ki a rendsze ra pontokat a képernyőre...

Kérdés:
Mit lehet elcseszni ahoz, hogy ilyen lassú legyen a kernel betöltés. (nem maga a boot-folyamat)
Nálatok kb meddig tart?

Csaba

Egyik naprol a masikra, kihalt mindket ldap serverunk ( egyik replica ), egesz pontosan TLS-sel nem megy egyik sem

a cert oks, nem jart le, legalabbis ugy tunik:

openssl verify -CAfile /etc/ldap/cacert.pem /etc/ldap/cert.pem /etc/ldap/cert.pem: OK

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 2 (0x2)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=UK, ST=United Kindom, L=London, O=University Of
Westminster, OU=CPC, CN=Bigbrother
CA/emailAddress=root@bigbrother.cscs.wmin.ac.uk
Validity
Not Before: May 5 15:07:12 2005 GMT
Not After : Jan 29 15:07:12 2008 GMT
Subject: C=UK, ST=United Kindom, L=London, O=University Of
Westminster, OU=CPC, CN=bigbrother.cscs.wmin.ac.uk
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):

ldap.log:

TLS trace: SSL_accept:before/accept initialization
TLS trace: SSL_accept:SSLv3 read client hello A
TLS trace: SSL_accept:SSLv3 write server hello A
TLS trace: SSL_accept:SSLv3 write certificate A
TLS trace: SSL_accept:SSLv3 write certificate request A
TLS trace: SSL_accept:SSLv3 flush data
TLS trace: SSL_accept:error in SSLv3 read client certificate A
TLS trace: SSL_accept:error in SSLv3 read client certificate A
connection_get(12): got connid=0
connection_read(12): checking for input on id=0
TLS trace: SSL_accept:SSLv3 read client certificate A
TLS trace: SSL_accept:SSLv3 read client key exchange A
TLS trace: SSL_accept:SSLv3 read finished A
TLS trace: SSL_accept:SSLv3 write change cipher spec A
TLS trace: SSL_accept:SSLv3 write finished A
TLS trace: SSL_accept:SSLv3 flush data
connection_read(12): unable to get TLS client DN, error=49 id=0
connection_get(12): got connid=0
connection_read(12): checking for input on id=0

vmi 5let?

Üdv

Van egy hdd, ext3 fájlrendszerrel, rm parancsal le lett törölve róla
minden. Hogyan hozhatnám vissza az adatokat róla?

Kösszi

Sziasztok!

Sokat hallani a firefox sebezhetosegek fenyegeto hadarol. Elegge ugy tunik, hogy a bongeszo a kritikus pont a szemelyes adatok biztonsaga tekinteteben.En a gepemen ezt a kovetkezokeppen oldottam meg: Letrehoztam egy browser nevu felhasznalot, es a sudoers fileba a kovetkezo bejegyzes kerult:
zsolt ALL=(browser) NOPASSWD:/usr/bin/iceweasel

Illetoleg a firefox ikonra kattintva a kovetkezo fut le:
sudo -H -u browser iceweasel

Ily modon hiaba hasznalnak ki barmilyen trukkos sebezhetoseget, a munkamat nem tudjak karositani.
Kerdesem, hogy szerintetek mik lehetnek egy ilyen megkozelites buktatoi, illetve ha ezek a buktatok orvosolhatoak, akkor miert nem terjedt mar el ez szelesebb korben? (gondolom nem en vagyok az elso ember a bolygon, akinek ez eszebe jut)
Koszonom a valaszokat.

Zsolt

Sziasztok!

A következőt szeretném megoldani, és eddig nem igazán sikerült:
van egy szerver progi, ami egy adott porton figyel. Be lehet rá telnetelni és ki lehet adni bizonyos parancsokat a számára.
Szeretném, ha egy scripttel meg tudnám oldani, hogy a telnettel belépve a portra (nincs semmilyen autentikáció) kiadjak egy parancsot, illetve ezt követően kilépjek és mindennek a kimenetét egy fájlba irányítsam. Magyarán két parancsot kellene átküldenem a telnettel, és a kimenetet feldolgoznom egy fájlban.

Valaki aki csinált már ilyet jó lenne ha megosztaná velem a módját.
Köszönet.

Sziasztok!

Redhat alapú linuxra szeretnék egy kis vírusvédelmet vakítani. Clamavot szeretném mailscannerrel dolgoztatni ami a levelekben keresne vírus. Nagyjából sikerült is belőni. Ez alapján dolgoztam:

necessary, execute the following commands before configuring MailScanner:

service postfix stop
chkconfig postfix off
Open /etc/postfix/main.cf and make sure that you add the following line:

header_checks = regexp:/etc/postfix/header_checks

Next, open the file /etc/postfix/header_checks and add this line:

/^Received:/ HOLD

This tells Postfix to move all messages to the HOLD queue. Now edit the file /etc/MailScanner/MailScanner.conf and change the following 6 settings, which are all near the top of the file:

Run As User = postfix
Run As Group = postfix
Incoming Queue Dir = /var/spool/postfix/hold
Outgoing Queue Dir = /var/spool/postfix/incoming
MTA = postfix
SpamAssassin User State Dir = /var/spool/MailScanner/spamassassin

Next, make sure Postfix can write to /var/spool/MailScanner/incoming and /var/spool/MailScanner/quarantine:

chown postfix.postfix /var/spool/MailScanner/incoming
chown postfix.postfix /var/spool/MailScanner/quarantine
Finally, execute the following commands and you're ready for testing:

mkdir /var/spool/MailScanner/spamassassin
chown postfix.postfix /var/spool/MailScanner/spamassassin
mkdir /var/spool/mqueue
chown postfix.postfix /var/spool/mqueue
touch /var/lock/subsys/MailScanner.off

Next, open the file /etc/postfix/header_checks and add this line:

/^Received:/ HOLD <<<<----- itt akadtam el. Ezt hova tegyem a header_checks filen belül? Valószínüleg ez a gond mert szerintem nem rakja be a levelet átvizsgálásra.

Működik már a mailscanner, és a clamav is de nem keres vírust mivel teszteltem egy levélben az "eicar" vírustesztével, de nemfogta meg.
Nemtudom mennyire írtam le érthetően a gondom. Remélem tudtok segíteni. hali!

Sziasztok!

Nem tudjátok hogy van e a squirrelmailben valami korlát az olyan levelet továbbításával kapcsolatban ahol a csatolmány pl 4 MB ?
Csak mert ha van egy levél melyhez csatolok mondjuk egy 200k-s doksit akkor teljesen rendben továbbítja, viszont ha egy 3MB-os wmv avagy zip vagy mindegy de ilyen méretű csatolmánnyal ellátott levelet szeretnék továbbítani akkor amikor aztmondom neki továbbítás akkor az nem müxik...nincs hibaüzenet, csak fehér browser...
Van valakinek valami ötlete mit állítsak át, és melyik konfig file-ban ?
A php.ini-ben 20Mb van beállítva, szóval ez nem lehet gond...

Hi,

kéne egy kis segítség...

Reggel az Inconsistent filesystem structure fogadott, mikor az Ubuntu-t akartam indítani (hdd).
Sebaj, bootolom LFS-t (hda), fsck, stb. reboot.

Ahelyett, hogy beindult volna, a fenti hibaüzenet fogadott, mikor a grubban ismét az Ubuntura nyomtam. STFW megvolt, nem sokra jutottam, mert a talált helpek nem segítettek, ennek oka az, hogy nincs hiba a filerendszerkben, legalábbis az fsck-k szerint.

Adatok:

hda: 160GB ATA
hdd: 80GB ATA

hda1: ext2 (16MB, nem használt)
hda5: reiserfs (LFS)
hda6: reiserfs
hda7: reiserfs
hda8: swap

hdd1: ntfs (XP)
hdd3: ext3 (Ubuntu 6.10)
hdd5: fat32

A grub a hda MBR-jében van, innen indítom a rendszereket.

grub menü:

LFS
ubuntu
ubuntu (régi kernel)
XP
memteszt

Amit csináltam:

- LFS gond nélkül indul, de ettől függetlenül a hda5-öt lecsekkeltem, nincs hiba.
- A hdd-ről egyik rendszer sem indul, sem az XP, sem az Ubuntu.
- LFS-t bootoltam, felmountoltam a hdd összes partícióját, ha már nem olvassa, de érdekes módon mégis olvassa mind az NTFS (XP), mind az ext3 (Ubuntu) mind a vfat partíciókat.
- Az Ubuntu partícióját lecsekkeltem, de nem ellenőrzött, mert azt mondja, tiszta.
- Nem hittem neki, ezért nyomtam force-t, és verbose-t is, de nincs bad block, nincs hiba. Itt a kimenet:

-($:~)-- fsck.ext3 -vf /dev/hdd3
e2fsck 1.39 (29-May-2006)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

157890 inodes used (15%)
3467 non-contiguous inodes (2.2%)
# of inodes with ind/dind/tind blocks: 8996/328/0
1855963 blocks used (90%)
0 bad blocks
0 large files

123375 regular files
20363 directories
133 character device files
43 block device files
2 fifos
462 links
13961 symbolic links (13047 fast symbolic links)
4 sockets
--------
158343 files

Kérdésem:

1. Miért van diszk olvasási hiba (a grub szerint), ha valójában nincs, hibátlanok a filerendszerek?
2. Mi a f....szt csináljak azon kívül, hogy legyalulom a hdd vinyót és újrarakok mindent, vagy kidobom a picsába?

Előre is kössz.

üdv

Üdv!
Az alábbi problémára kérnék szépen segítséget:

Van egy tűzfal, az eth0 lába az internetre néz, az eth1 lába meg a belső hálózatra - mondjuk 192.168.1.0/24-es tartomány.
A belső háón van egy webszerver melyen chroot-ban futnak httpd-k. Minden weboldalhoz egy. Melyek természetesen más-más porton hallgatóznak. A tűzfalon fut szintén egy apache httpd mely proxy-ként működve továbbküldi a kérést a megfelelő portra, a webszerverre.
Ez teljesen szépen működik nincs is vele baj. A gond ott kezdődik számomra, hogy az ügyfelek részére biztosítani kell a webtartalomhoz elérést. Mondjuk sftp vagy inkább scp segítségével. De mivel ott van a tűzfal a kapcsolat közt nem tudom elérni kintről a webszervert. Nem szeretném, ha az ügyfeleknek valamilyen ssh tunnel megoldást kéne használniuk. Van valamilyen lehetőség erre?

Köszönöm!
Jedite

Üdv!

Van egy régi 2.0.40-es konfigurációm, ami eddig nagyon jól működött. Pár napja rendszertelen időközönként a lekért URL helyett egy oldalt (worm) ad le.

Látott már vki ilyet?