Linux-haladó

Általános védelmi hiba, Mandriva 2006 + SunFire 1200 + 64 bit + SMP

Fórumok

Sziasztok!

Egy ideje nem tudtam írni, mert nagyon el voltam foglalva a Pestre költözéssel és az új munkahelyemmel. De mostanában van egy probléma az egyik Linuxos szerveremmel, amiről szerettem volna kikérni a véleményeteket.

A szóbanforgó cucc egy Sun Fire 1200, amire anno Mandriva Linux 2006-ot raktam. Na, most ez a szerver hetente vagy max. másfél hetente csontra fagy (uptime változó, de <2 hét). Eddig nem nagyon volt időm utánajárni a problémának, csak be-beszaladgáltam a Victor Hugo utcára újraindítani (ott lakok gyak. a szomszédban). Most, hogy lecsillapodtak egy kissé a dolgok, a végére szeretnék járni.

Úgy mellesleg: Ismerősök erőteljesen bíztatnak arra, hogy Sun hardvereken felejtsem el a Linuxot. Azt mondják, hogy Sun cuccra csak Solarist "szabad" pakolni. Megint mások arra esküsznek, hogy a különböző BSD-k (nevezetesen: Open- vagy max. FreeBSD) közül kellene választanom. (Valaki amúgy tréfából [vagy nem...] azt is benyögte, hogy rakjak fel Má$t mer' az biztos jó...) Amiben a két oldal megegyezik az az, hogy a Linux, pontosabban a kernel eleve "instabil" 64 biten, és ezt állítólag csak "súlyosbítja", hogy SMP módban használom. Van ebben valami szerintetek? Hogy egyszerűen és primitíven fogalmazzam meg a kérdést: "Akkor most rakjak fel Solarist vagy OpenBSD-t Linux helyett és minden bajom semmivé lesz?" Hm? :)

Visszatérve a problémára... Alább látható a releváns logbejegyzés az /etc/messages-ből:


Jul 10 08:08:00 sansz kernel: general protection fault: 0000 [1] SMP
Jul 10 08:08:00 sansz kernel: CPU 0
Jul 10 08:08:00 sansz kernel: Modules linked in: md5 ipv6 ipt_REJECT ipt_LOG ipt_state ipt_pkttype ipt_set ipt_CONNMARK ipt_MARK ipt_ROUTE ipt_connmark ipt_owner ipt_recent ipt_iprange ipt_physdev ipt_multiport ipt_conntrack iptable_mangle ip_set_portmap ip_set_macipmap ip_set_ipmap ip_set_iphash ip_set ip_nat_irc ip_nat_tftp ip_nat_ftp iptable_nat ip_conntrack_irc ip_conntrack_tftp ip_conntrack_ftp ip_conntrack iptable_filter ip_tables tg3 forcedeth af_packet ide_cd loop tsdev usbmouse usbhid usbkbd ehci_hcd ohci_hcd usbcore evdev reiserfs sd_mod sata_nv libata scsi_mod
Jul 10 08:08:00 sansz kernel: Pid: 155, comm: pdflush Not tainted 2.6.12-12mdksmp
Jul 10 08:08:00 sansz kernel: RIP: 0010:[__wake_up_bit+8/48] <ffffffff801a7a58>{__wake_up_bit+8}
Jul 10 08:08:00 sansz kernel: RIP: 0010:[<ffffffff801a7a58>] <ffffffff801a7a58>{__wake_up_bit+8}
Jul 10 08:08:00 sansz kernel: RSP: 0018:ffff81007fd21ca8  EFLAGS: 00010292
Jul 10 08:08:00 sansz kernel: RAX: 3df330a000d80e48 RBX: ffff810002690098 RCX: 0000000000000040
Jul 10 08:08:00 sansz kernel: RDX: 0000000000000000 RSI: ffff810002690098 RDI: 3df330a000d80e40
Jul 10 08:08:00 sansz kernel: RBP: 0000000000001000 R08: ffff81005f160ea0 R09: 0000000000000004
Jul 10 08:08:00 sansz kernel: R10: 00000000ffffffff R11: 0000000000000000 R12: ffff81005f160ea0
Jul 10 08:08:00 sansz kernel: R13: ffff81007fe82380 R14: ffff81007fe82440 R15: 00000000000019f5
Jul 10 08:08:00 sansz kernel: FS:  00002aaaac195e80(0000) GS:ffffffff804d5d00(0000) knlGS:00000000556b86c0
Jul 10 08:08:00 sansz kernel: CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
Jul 10 08:08:00 sansz kernel: CR2: 00002aaaabcf6000 CR3: 0000000021a34000 CR4: 00000000000006e0
Jul 10 08:08:00 sansz kernel: Process pdflush (pid: 155, threadinfo ffff81007fd20000, task ffff81007fd1ce70)
Jul 10 08:08:00 sansz kernel: Stack: ffff81007fe82380 ffffffff801b9e13 ffff810002690098 ffffffff801e436d
Jul 10 08:08:00 sansz kernel:        00000000000019f5 0000000000002000 0000000000000000 ffff81007faca400
Jul 10 08:08:00 sansz kernel:        ffffc20000024000 0000000000000002
Jul 10 08:08:00 sansz kernel: Call Trace:<ffffffff801b9e13>{unlock_page+35} <ffffffff801e436d>{__getblk+621}
Jul 10 08:08:00 sansz kernel:        <ffffffff801a7450>{keventd_create_kthread+0} <ffffffff8805f619>{:reiserfs:do_journal_end+1241}
Jul 10 08:08:00 sansz kernel:        <ffffffff8805fe24>{:reiserfs:do_journal_begin_r+52}
Jul 10 08:08:00 sansz kernel:        <ffffffff801a7a98>{wake_up_bit+24} <ffffffff801bfe40>{pdflush+0}
Jul 10 08:08:00 sansz kernel:        <ffffffff801bfe40>{pdflush+0} <ffffffff801a7450>{keventd_create_kthread+0}
Jul 10 08:08:00 sansz kernel:        <ffffffff8804d830>{:reiserfs:reiserfs_sync_fs+64} <ffffffff801e62dd>{sync_supers+125}
Jul 10 08:08:00 sansz kernel:        <ffffffff801bf3da>{wb_kupdate+42} <ffffffff801bfe40>{pdflush+0}
Jul 10 08:08:00 sansz kernel:        <ffffffff801bff7c>{pdflush+316} <ffffffff801bf3b0>{wb_kupdate+0}
Jul 10 08:08:00 sansz kernel:        <ffffffff801a76c9>{kthread+217} <ffffffff8018ba10>{schedule_tail+64}
Jul 10 08:08:00 sansz kernel:        <ffffffff8010f6d3>{child_rip+8} <ffffffff801a7450>{keventd_create_kthread+0}
Jul 10 08:08:00 sansz kernel:        <ffffffff801a75f0>{kthread+0} <ffffffff8010f6cb>{child_rip+0}
Jul 10 08:08:00 sansz kernel:
Jul 10 08:08:00 sansz kernel:
Jul 10 08:08:00 sansz kernel: Code: 48 3b 47 08 48 89 34 24 89 54 24 08 74 12 48 89 e1 ba 01 00
Jul 10 08:08:00 sansz kernel: RIP <ffffffff801a7a58>{__wake_up_bit+8} RSP <ffff81007fd21ca8>

Nem tudom miért, de nekem így elsőre gyanús a sata_nv modul (NVidia cuccokkal már volt ezelőtt bajom). De nem akarok befolyásolni senkit a tévelygéseimmel... Ötletek? :)

Előre is hálásan köszönök minden hozzászólást!!

Marvell Yukon Gigabit Ethernet mii-tool hiba

Fórumok

Tiszteletem!

Segítségeteket kérném hálókártya konfiguráláshoz.

A lényeg:
Adott egy Marvell Technology Group Ltd. Yukon Gigabit Ethernet 10/100/1000Base-T Adapter hálókártya.
Rendszer: Linux Debian Sarge Kernel 2.6.17

mii-tool-ra a következő kapom vissza: SIOCGMIIPHY on 'eth0' failed: Bad address no MII interfaces found

Valakinek lenne esetleg ötlete, hogy hogy lehet beállítani?
A normális válasznak valami ilyesminek kellene lennie: eth0: negotiated 100baseTx-FD, link ok

Előre is köszi ...

Üdv:

Z

Egér irányítása billentyűzetről?

Fórumok

Sziasztok.

Szerintetek hogy lehetne megoldani, hogy az egérkurzort billentyűzetről tudjam irányítani (fel, le, jobbra, balra, esetleg ferdén ide-oda) és egérkattintást is tudjak csinálni! A má$ik rendszer alatt volt erre egy egyszerű megoldás a kisegítő lehetőségek között! Itt hogyan tudnám megoldani?

Köszi a tippeket!

u.i.: Google-val kerestem, de nem sok sikerrel :(, igazából azt sem tudom konkrétan hogyan keressek erre!

Shell 'gepelesi sebesseg' limitalasa

Fórumok

Hi!

Az lenne a kerdesem, hogy hogy lehet megoldani, hogy a bejelentkezett felhasznalok ne tudjanak bizonyos sebessegnel gyorsabban gepelni. Ssh, esetleg telnet alapu erdekelne leginkabb.

Tehat ha mondjuk 10karakter/sec fole megy (gyakorlatilag azert, mert egy file-t be akar illeszteni), akkor nem veszi figyelembe az elkuldott karaktereket.

Ezt szerintem valami ssh (/telnet) tuninggal lehetne megoldani, csak addig nem akarok belenyulni ezekbe, amig van remeny, hogy erre van valami kulon opcio.

Elore is koszi.

PS: Igen, telnet, mert olyan helyre kell, ahol nem szamit a biztonsag.

By(t)e
TBS::Antiemes

csak ftp re natolni

Fórumok

sziasztok !

adott egy háló ahol csak proxyval mehetnek ki a userek.

Szeretném 1 gépre engedni a natolást , de csak ftp re.

ezzel nem ment...

iptables -t nat -A POSTROUTING -s 10.0.0.51 -j MASQUERADE -p tcp --dport 21

köszi a segítséget.

üdv

G.

2 webszerver közötti választás iptables-szel. lehetséges?

Fórumok

A következőt kéne megoldanom.
Van 2 webszerver és elötte lenen egy tűzfal. Egy nyilvános ip címmel rendelkezik a tűzfal, de több domain is be van regisztrálva(sőt aldomain is.) hozzá. Meg tudom-e oldani azt iptables-sel vagy mással, hogy ha jön egy kérés a www.mydomain.hu-ra a 80 v. 443 porton, akkor az menjen tovább az 1. webszerver fele, de ha a www.my2domain.hu, vagy a special.mydomain.hu-ra jön kérés, akkor az már a 2. webszerver fele menjen?
Milyen "kapcsolót" kéne hazsnálnom az netfilterben, hogy a kérés célját megkapjam, vagy egyáltatlán ez lehetséges?
Vagy csak az apach-csal tudom ezt megoldani, hogy minden kérés az egyik szerver fogad, max utánna átdobja a másiknak?
As segítségeteket előre is köszönöm

Samba: megőrülök

Fórumok

Üdv!

Próbálom beállítani a sambát, mindenki által írható, jelszó nélkül elérhető megosztást szeretnék, de mindig jelszót kér... tudtok segíteni?

smb.conf:

[global]
netbios name = GEPNEV
server string = Server
workgroup = MSHOME
announce version = 5.0
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE SO_RCVBUF=8192 SO_SNDBUF=8192
security = share
null passwords = true
username map = /etc/samba/smbusers
wins support = yes
name resolve order = wins lmhosts hosts bcast
dns proxy = yes
wins support = yes
os level = 65
preferred master = yes
domain master = yes
local master = yes
hosts allow = 192.168.1.1 192.168.1.2 192.168.1.3 192.168.1.200
printing = CUPS
printcap name = CUPS
syslog = 1
syslog only = yes

[print$]
path = /var/lib/samba/printers
browseable = yes
guest ok = yes
read only = yes
write list = root
create mask = 0664
directory mask = 0775
[printers]
path = /tmp
printable = yes
guest ok = yes
browseable = no
public = yes
writable = yes
disable spoolss = yes
print command = /usr/bin/lpr-cups -r %s
[Share]
path = /path/to/share
public = yes
writable = yes
browseable = yes
create mask = 0777
directory mask = 0777
force user = nobody
force group = nogroup

mysql eszi a cpu-t

Fórumok

Hello

Frissitettem mysql-4.1.20-ra es elinditva folyamatosan elkezd noni a load erteke. 3 mysqld processz eszi a cpu-t. A logba nem kerul semmi erre vonatkozolag. Ha debuggal forditom akkor nincs ez a jelenseg, de akkor meg konnyen elszall. Igy kisse hasznalhatatlan, mert 1-2 ora alatt iszonyat magas loadot produkal. Nem a felhasznalok terhelik, mert ha nem csinal senki semmit akkor is zabalja a procit. Talalkozott mar valaki ilyennel? Illetve hogy lehetne kidebuggolni? Stracelni nem lehet.

Rendszerprocesszek default prioritásának átállítása

Fórumok

neha nagyon belassitja a gepet ha masolok vagy a hatterben vmilyen daemon nagyon megeszi az eroforrasokat... be lehet vhol allitani hogy ezek alacsonyabb prioritassal fussanak mint az userlevel dolgok?

tehat pl ha epp updatedb fut, es en elkezdek valamit csinalni userkent, akkor a prioritas az enyem legyen...