A SELinux érdekes állatfaj, a használatával biztonságosabb lehet a szerverünk, de néha bele tudunk futni fura hibákba, amelyeknek nem feltétlen értjük a forrását. Ilyen hiba lehet az, ha egy saját magunk által írt Munin plugin nem tud lefutni, s az alábbi hibát írja a logba:
2012/06/22-13:20:05 [13773] Error output from jstat_confluence: 2012/06/22-13:20:05 [13773] Can't exec "/etc/munin/plugins/jstat_confluence": Permission denied at /usr/share/perl5/vendor_perl/Munin/Node/Service.pm line 215, <STDIN> line 37. 2012/06/22-13:20:05 [13773] # ERROR: Failed to exec. 2012/06/22-13:20:05 [13773] Service 'jstat_confluence' exited with status 42/0. 2012/06/22-13:20:05 [13773] Error output from jstat_confluence: 2012/06/22-13:20:05 [13773] Can't exec "/etc/munin/plugins/jstat_confluence": Permission denied at /usr/share/perl5/vendor_perl/Munin/Node/Service.pm line 215, <STDIN> line 38. 2012/06/22-13:20:05 [13773] # ERROR: Failed to exec. 2012/06/22-13:20:05 [13773] Service 'jstat_confluence' exited with status 42/0.
Ránézésre semmi ok nincs arra, hogy ne tudná lefuttatni az adott szkriptet, kézzel indítva remekül lefut, az adott felhasználó nevében is lefut, mindenféle variációban lefut, de a Munin nem futtatja le. Ilyenkor erősen gyanakodjunk arra, hogy a SELinux nem engedi az adott hívást...
Persze nem egyszerű erre rájönni, mert a SELinux alapból nem írja az audit.log állományba azt, hogy valamit megtagadott, ehhez át kell kapcsolnunk a -D paraméter használatával egyfajta hibakereső módba:
# semodule -DB
Majd erősen figyeljük a munin-releváns eseményeket az aud it.log állományban:
# tail -f /var/log/audit/audit.log | grep munin type=AVC msg=audit(1340364509.760:42854): avc: denied { execute } for pid=14980 comm="munin-node" name="jstat" dev=xvda1 ino=135170 scontext=unconfined_u:system_r:munin_t:s0 tcontext=unconfined_u:object_r:munin_etc_t:s0 tclass=file type=SYSCALL msg=audit(1340364509.760:42854): arch=c000003e syscall=59 success=no exit=-13 a0=160b4a0 a1=160b400 a2=15f1c10 a3=7fff0de26710 items=0 ppid=14979 pid=14980 auid=0 uid=99 gid=498 euid=99 suid=0 fsuid=99 egid=498 sgid=0 fsgid=498 tty=(none) ses=4247 comm="munin-node" exe="/usr/bin/perl" subj=unconfined_u:system_r:munin_t:s0 key=(null)
Meg is van a bűnös, már csak létre kell hoznunk a fenti tartalom alapján egy egyedi policy fájlt:
# cat /tmp/munin_jstat_policy | audit2allow -M munin_jstat_policy ******************** IMPORTANT *********************** To make this policy package active, execute: semodule -i munin_jstat_policy.pp # semodule -i munin_jstat_policy.pp # semodule -l | grep munin_jstat munin_jstat_policy 1.0
Lezárásképp állítsuk vissza az audit.log naplózását az eredeti állapotra:
# semodule -B
Majd ellenőrizzük le az eredményt, s ha továbbra is hibás működést találunk, akkor ismételjük meg (az előző policy sértés mögé hozzáírva az újabbakat), amíg kapunk elutasító audit.log kimenetet az adott hivással kapcsolatban.
Ahogy olvasható a bevezető oldalon, "a meglévő fizikai hardver – bár stabil és strapabíró – sajnos elavult, lassú, továbbá nehezen és drágán bővíthető". A bővítés a Confluence motorra való migrálás okán vált szükségessé, mivel a nagyobb terhelést kapó wiki oldalnak nagyobb lett az erőforrás igénye, így a netdiag.hu mérései csúnya képet mutattak az utóbbi egy hónapban:
Igaz, voltak szép napok is:
A problémák forrása alapvetően a Confluence volt, amely több erőforrást igényel azonos forgalom esetén, mint a régi JavaForum2.0 portál – hozzá kell tenni, hogy sokkal többet is tud, de amikor a szerveren időzített mentések futottak, illetve több egyidejű kérés esett be, akkor a válaszidő túllépte a 12 másodpercet, amelyet a netdiag.hu már hibának jelzett és valóban sokban rombolja a felhasználói élményt a lassú weboldal.
Tegnap éjjel átmigráltam a teljes Confluence tartalmat az új szerverre, remélve, hogy elmúlnak a problémák, ám új problémával szembesültem:
Ahogy a grafikonon látszik, reggel negyed nyolc körül egy SMS-re ébredtem, hogy áll az oldal, a szerverre belépve az fogadott, hogy a Java processz nemes egyszerűséggel megszűnt létezni, a történtekről egy hs_err_pid26238.log fájl árulkodott, amely eleje szerint a JVM belefutott egy helyrehozhatatlan hibába:
# # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007ff2e511ed04, pid=26238, tid=140681185855232 # # JRE version: 6.0_24-b24 # Java VM: OpenJDK 64-Bit Server VM (20.0-b12 mixed mode linux-amd64 compressed oops) # Derivative: IcedTea6 1.11.3 # Distribution: CentOS release 6.2 (Final), package rhel-1.48.1.11.3.el6_2-x86_64 # Problematic frame: # J java.lang.String.getBytes(Ljava/lang/String;)[B # # If you would like to submit a bug report, please include # instructions how to reproduce the bug and visit: # http://icedtea.classpath.org/bugzilla # --------------- T H R E A D --------------- Current thread (0x00007ff2e8982800): JavaThread "Java2D Disposer" daemon [_thread_in_Java, id=26321, stack(0x00007ff2e40c0000,0x00007ff2e41c1000)]
És még kétszer a mai nap:
-rw-r--r--. 1 confluence users 168672 jún 20 11.25 hs_err_pid14012.log -rw-r--r--. 1 confluence users 167009 jún 20 07.08 hs_err_pid26238.log -rw-r--r--. 1 confluence users 164023 jún 20 08.46 hs_err_pid4643.log
A fájlokban lévő ok közösnek tűnt:
Stack: [0x00007ff2e40c0000,0x00007ff2e41c1000], sp=0x00007ff2e41bef50, free space=1019k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) J java.lang.String.getBytes(Ljava/lang/String;)[B V [libjvm.so+0x4b8fa8] AsyncGetCallTrace+0xa4e38 V [libjvm.so+0x4b8108] AsyncGetCallTrace+0xa3f98 V [libjvm.so+0x4c4266] JNI_CreateJavaVM+0xf86 V [libjvm.so+0x4c4fb4] JNI_CreateJavaVM+0x1cd4 C [libjava.so+0x18360] JNU_GetStringPlatformChars+0x640 C [libfontmanager.so+0xad21] Java_sun_font_FreetypeFontScaler_initNativeScaler+0x2b1
Mindegyik a libfontmanager.so működésével kapcsolatos, amely a JVM része:
-rwxr-xr-x. 1 root root 238544 jún 13 16.52 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/libfontmanager.so
Javításképp feltettem egy Oracle JDK csomagot, amely kicsit hosszabb, mint az OpenJDK csomagban lévő:
-rwxr-xr-x. 1 root root 671972 máj 9 19.28 /opt/jdk1.6.0_33/jre/lib/amd64/libfontmanager.so
A Confluence most már ezzel a Java csomaggal fut, remélem ezzel megoldódik a probléma, ez a holnapi nap során talán kiderül...