AIX

Így áll a locale:

$ locale
LANG=en_US.ISO8859-1
LC_COLLATE="en_US.ISO8859-1"
LC_CTYPE=hu_HU.ISO8859-2
LC_MONETARY="en_US.ISO8859-1"
LC_NUMERIC="en_US.ISO8859-1"
LC_TIME="en_US.ISO8859-1"
LC_MESSAGES="en_US.ISO8859-1"
LC_ALL=

Tehát csak a LC_CTYPE magyar, semmi más. Na lássuk, mi történik:

$ java
Használat: java [-opciók] osztály [arg-ok...]
           (egy osztály végrehajtása)
   vagy  java [-opciók] -jar jarfájl [arg-ok...]
           (egy jar fájl végrehajtása)

Akkor kedvem lenne ilyenkor egy kalapáccsal szétverni a monitort...

hsearch_r visszaadott értéke...

Ugye, ahogy azt a mórocska elképzeli... AIX-ben a fordítottja annak, ami linux-ban:

AIX: 0=van találat
linux: 0=nincs találat

Mondjuk az AIX-os leírásra nem hivatkozhatok, mert olyat nem találok, csak a sima hsearch-ét.

Persze megkerüljük ezt is, mint minden mást...

Hát pl:

== 1 ==

/usr/local/libexec/mc/extfs.d/uar -ban:

volt: XAR=ar
lett: XAR='ar -X32_64'

== 2 ==

/usr/local/libexec/mc/ext.d/misc -ben '*so*' fájlok kezelése:

@@ -29 +29 @@
-         file "${MC_EXT_FILENAME}" && nm -C -D "${MC_EXT_FILENAME}"
+         file "${MC_EXT_FILENAME}" && nm -X32_64 "${MC_EXT_FILENAME}"

== 3 ==

/usr/local/share/mc/mc.lib-ben új betoldás (végére):

[terminal:konsole]
copy=xterm

[terminal:konsole-256color]
copy=xterm

== 4 ==

/usr/local/share/mc/syntax/Syntax-ban Pro*C támogatás:

file ..\*\\.(c|pc)$ C\sProgram
include c.syntax

== 5 ==

$prefix/etc/mc/mc.ext: zip-fájlok támogatása (a regex-es részből másolva az Open és View részeket):

# zip

regex/i/\.(zip|jar|war|ear)$
        Open=%cd %p/uzip://
        View=%view{ascii} $prefix/libexec/mc/ext.d/archive.sh view zip

megj a #3-hoz:
a konsole termináltípus előnye, hogy a kbs=\177, ami a linuxon alapértelmezés, tehát így az a lelki elégétételünk lehet, hogy a terminfo-val összhangban vagyunk (egy dash vagy ksh használata esetén ez előnyös lehet);
ennek a résznek az a haszna, hogy ezután a Shift+Fn gombok úgy működnek, ahogy várnánk, hogy működjenek (pl Shift+F4=edit new file)

Ez most nem költői kérdés, a mysql fordításához kellene, amihez először őt magát is szeretném lefordítani (persze nem megy, naná). Továbbá szeretném tudni, hogy mi is ez? Mármint nem a marketing szöveget, hanem az effektív információt; úgy értem a leírásokat, hogy ez a 'configure' kiváltója akar lenni, de úgy tűnik (legalábbis abból, hogy a saját fordításhoz önmagát is haszálja), hogy a make feladatát is átveszi, illetve abba is belekavar.

Hát, ha ő mondja, én elhiszem...

0509-130 Symbol resolution failed for /usr/local/lib/libstdc++.so because:
        0509-136   Symbol __fd_poll (number 33) is not exported from
                   dependent module /usr/lib/libc.a(shr.o).

Ez egy AIX 5.2, a libstdc++ RPM-ből jött, mégpedig ebből: libstdc++-4.6.2-1.aix5.2.ppc.rpm

Márpedig ez nagyon egy version-incompatibilitynek tűnik...

Megjegyzés: az az igazság, hogy gcc-t még sosem mertem forrásból fordítani... lehet, hogy a karma erői most erre akarnak rávenni?

Van egy ilyen részlet a crypto/ppccpuid.s fájlban:

.globl  .OPENSSL_altivec_probe
.align  4
.OPENSSL_altivec_probe:
.long   0x10000484
        blr
.long   0
.byte   0,12,0x14,0,0,0,0,0

ami a debuggoláskor így néz ki:

Breakpoint 1, 0xdf530548 in OPENSSL_altivec_probe ()
   from /usr/local/lib/libcrypto.so.1.0.1
(gdb) display/i $pc
1: x/i $pc
=> 0xdf530548 <OPENSSL_altivec_probe>:  vor     v0,v0,v0
(gdb) si

Program received signal SIGILL, Illegal instruction.
0xdf530548 in OPENSSL_altivec_probe () from /usr/local/lib/libcrypto.so.1.0.1

a hívó a crypto/ppccap.h, abban egy ilyesmi részlet van:

if (sigsetjmp(ill_jmp,1) == 0) {
        OPENSSL_altivec_probe();
        OPENSSL_ppccap_P |= PPC_ALTIVEC;
}

ez előtt volt egy sigaction, ami beállított egy handlert, ami lenyelné a hibát:

static void ill_handler (int sig) { siglongjmp(ill_jmp,sig); }

Namostan nekem van olyan helyzetem (Apache->Php->OpenSsl, továbbá saját PHP bővitmény is van), amikor ez valamiért nem így történik, hanem megáll a futás.

Előre bocsátom, hogy nem vagyok admin/rednszergizda stb.

Sima userként szeretném elérni, hogy egy AIX serverrről Windows Authentikációval be tudjak logolni as MSSQL szerverre és tudjak SQL scriptketet futtatni (SAS-ból, de ez azt hiszem ez mindegy a probléma szempontjából).

Ha kapok userID-t a SQL szervere működik a kapcsolat. (Azért nem jó ez, mert több user szeretne több szervert is használni amire WindowsAuth-tal logolbe )

Ha átváltok WindowsAuth-ra, akkor ezt kapom:

Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.

Ez az én olvasatomban azt jelenti, hogy az AIX server nincs a Windows Domainban, gondolom "fel kellene venni a megfelelő listára" ;), és esetleg kell valamit "telepíteni" AIX alá, hogy működjön a WindowsAuth (Szerintem nem, de javítsatok ki ha tévedek.)

Azért kérdezek itt, mert mind két oldal (SQL Adminok , AIX Adminok) egymásra mutogat, hogy a másik oldalon van a probléma. (És nem-nem beszélnek egymással :( )

Szóval jó lenne valami tanács, hogy melyik osztályt rugdossam tovább. ;)

Az előző kettő folytatása.

AIX veteránok véleményére lennék kíváncsi az alábbi probléma kapcsán, köszönettel.

Adott egy AIX ssh kliens és egy Linux ssh szerver, sok hop távolságra egymástól. Kettejük között található egy ipsec gateway, amelyen az MTU 1294 byte.

AIX->Linux irányban működőképes a "traceroute" parancs (külön "tracepath" nincs, de az AIX traceroute-ba bele van építve az MTU csökkentése szükség esetén). Ez a pontos PMTU-t nem keresi meg (cca. 1400-ról mindjárt cca. 1000-re ejti, majd nem megy feljebb; a valós gateway MTU a kettő között van).

Linux->AIX irányban kezdeményezve sem a traceroute, sem a tracepath-t, sem a beépített PMTUD nem működik (brutál tűzfalszabályok vannak); jobb híján a helyi 1500-as MTU-t veszi PMTU-nak a Linux.

A probléma az, hogy az alábbi parancs:

aix$ ssh linux cat bigfile

"megakad".

tcpdump szerint az AIX a SYN packet-be 1300-at rak MSS-nek.

Linux a SYN/ACK-ba 1460-as MSS-t tesz (PMTU - IP hdrs - TCP hdrs == 1500 - 20 - 20 == 1460, ahol ugye a PMTU=1500 nem valós, csak éppen a tűzfalszabályok miatt nem találja meg a Linux PMTUD az igazi PMTU-t, ezért a helyi MTU-val, 1500-zal dolgozik).

A csomagokon be van nyomva a DF (don't fragment). Ez feltehetően annak a következménye, hogy PMTUD után nincs értelme fragmentálni.

Amikor a Linux az első 1300 byte-os csomagot küldi (az AIX-tól kapott MSS-nek megfelelően), DF-fel, akkor a gateway az út közepén ezt kikukázza, és küld egy "Fragmentation required / DF flag set" ICMP csomagot a Linux ssh szervernek. Ennek nincs hatása (bár úgy tűnik, megérkezik); a Linux nem kezd tördelni, és a kimenő szegmensméretet sem csökkenti.

Az alábbi kerülőket találtuk:

• AIX MTU csökkentése 1294-re vagy alája. Ekkor az AIX által a SYN-ben küldött MSS is kisebb, így a Linux kisebb csomagokat küld, amelyek átjutnak az ipsec gateway-en.
• Linux-on a
  

  net.ipv4.ip_no_pmtu_disc

  sysctl-lel kikapcsolva a PMTUD-t úgy látszik, hogy a "fragmentation required" üzeneteket a Linux figyelembe veszi, és tördel.

Mindkettő statikus/globális beállítás, ezért kellemetlen.

A kérdésem az, hogy ennek az egésznek lehet-e oka az AIX szerver félrekonfigurálása. A weben találtam

tcp_pmtu_discover

és

tcp_mssdflt

nevű kernelbeállításokat. Az olvasottak alapján úgy gondolom, hogy ha ezeket rosszul állítják be (= PMTUD kikapcsolása, plusz mind az interface MTU, mind az interface-hez (ill. a route-hoz) tartozó default MSS-nek a gateway MTU fölé állítása), akkor az indokolja a látottakat.

Lényegében az AIX által kiküldött 1300-as MSS valótlan (korrekt PMTUD-nek nem lehet az eredménye!), és azok a csomagok, amelyeket a Linux valóban ekkorára méretez, elakadnak a gateway-ben. Az onnan származó "fragmentation required / DF set" ICMP üzeneteket pedig a Linux nem veszi figyelembe, amikor a saját PMTUD-je nincs letiltva.

Látott már valaki ilyet?

Köszönöm.

Holnap jon a POWER7+!

"Announcement Of Cutting-Edge POWER7+ Processors Expresses IBM(r)'s Ongoing Commitment Toward AIX(tm) System Administrators" :DD