NevemTeve's blog

Pöttering áldja meg az sshd-t...

Akarom mondani, a haladás nem áll meg, tehát az sshd-t már a systemd indítja a kis laptopomon. És az is állítja meg. Kb. 30 másodperc után. Mert valamiért úgy érzi, hogy nem indult el. Tök jó, hogy ilyen rendes szoftverek vannak, amik gondoskodnak debuggolnivalóról...

Mondjuk egy zavaros pontot azért látok a dologban: ha azt hiszi, hogy nem indult el, akkor mit állít le? Szóval azért tudja, hogy 'jé van itt egy process, amit én indítottam', csak valamiért nem vagyok elégedett vele, hát leállítom'

Szerk: most leírom a legsötétebb gondolatot, ami csak eszembe jutott, és reménykedem, hogy nem ez lesz az igaz: Debianék belemaszt...mesterkedtek az OpenSSH-ba, hogy systemd-kompatibilis legyen, ami persze az eredeti gyári termékben nincs benne. Ezek szerint a megoldás a Type=notify helyett Type=forking lehetne.

Uram, nekünk posta kell!

http://mek.oszk.hu/12500/12517/12517.htm
Mondta a bennszülött miniszter országa egyetlen fehér lakójának.

Hát most a tomcat-native!configure van úgy vele, hogy neki $JAVA_HOME/include/jni_md.h nélkül nem sors a sorsa.

Az semmiképpen sem az ő hibája, hogy egyes implementációkban ugyanez $JAVA_HOME/include/jniport.h néven létezik, továbbá hogy ő ezt a fájlt igazából nem is használja, csak a $JAVA_HOME/include/jni.h-t, ami aztán valahogy gondoskodik a többiről.

Túl nehéz feladat 'mcview' számára

Ez itt túl nehéz feladat a 'mcview'-nek, belefagy:


mcview /usr/java5/include/jni.h

Szerk: aljas rágalom, a 'file' utility döglött meg (akit a mcview hívott meg). Innen már kezd halványan ismerős lenni a történet, mindjárt visszakeresgélek...

Szerk: ez volt az előzmény: https://hup.hu/node/155854, ott a file-5.29 volt a gond, most a file-5.32, hátha azóta van újabb.

Szerk: Innen próbálkozom az 5.34-gyel: ftp://ftp.astron.com/pub/file/

Szerk: Hát ezzel is.

libcrypto.so.1.1: no version information available

Előzmény itt: libcrypto.so.1.0.2: no version information available
Akkor abban maradtam, hogy jó, Debianék biztos valamilyen jócselekedtképpen másképp linkelik az OpenSSL-t, mint a gyártó, ezért az én házilag fordított OpenSSL-em nem jó a Debian-os binárisoknak.

Nomost itt az 1.1.1, amire ismerős üzenetet kapok:

Nyomasek Bobó megint segített nekem....

Akarom mondani, amikor 2017. júliusában a gcc-4.9.4-et forrásból telepítettem, akkor Bobó úgy látta, hogy a /usr/include/openssl/bn.h nem jól kvarálodik a zengével, ezért neki javított változatot kell létrehoznia, és elhelyezni a könnyen megtalálható /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.4/include-fixed/openssl könyvártban.

Az már semmiképpen sem az ő hibája, hogy azóta a világ haladt, az OpenSSL-1.1.1 is elérkezett, és az ő áldásosan megjobbított, de egyébként elavult fájlja miatt nem fordult a tomcat-native-1.2.17...

OpenSSL-1.1.1 megérkezett!

OpenSSL-1.1.1 megérkezett! Persze egyből jó is, ugye?
Madjnem.
A certificate-request-generálásnál megáll, ha a 'STate' vagy az 'OrganizationUnit' üres:


1:error:0D07A098:asn1 encoding routines:ASN1_mbstring_ncopy:string too short:crypto/asn1/a_mbstr.c:100:minsize=1

https://github.com/openssl/openssl/issues/7215

Szerk: Azt a jótanácsot kaptam, hogy teljesen hagyjam ki a "subject"-ből az üres részeket (SUBJ=/C=HU/.../ST=/.../OU=/...), akkor jó lesz. Kipróbáltam, jó lett.

2018.10.29. 06:40 Kiszivárgott, hogy az 1.1.1 sorozatban is a végére tett betűk fogják jelenteni a patchverziót. Ennek alapján, ha mondjuk lesz egy 1.1.1a, akkor abból AIX-on lehet egy ilyesmi láncolat:


libssl.so.1.1.1.a -- maga a shared lib; major=1.1, minor=1.a
libssl.so.1.1     -- szimlink az előzőre, csak major, a használó programok erre dependálnak
libssl.so         -- szimlink az előzőre/elsőre, nem használjuk semmire
libssl.la         -- programok szerkesztésekor (linkage) használjuk, ebből tudjuk meg az aktuális libraryt (a libssl.so.1.1)

Apache: OPTIONS * mod_jk ellen

Ki lehet a hibás, ha ilyen üzenet van a mod_jk.log fájlban:


[Thu Sep 06 10:40:14.221 2018] [942126:1] 
[emerg] jk_servlet_normalize::jk_util.c (2188): [*] does not start with '/'.

httpd: Apache/2.4.34
mod_jk: tomcat-connectors-1.2.44

Ugyebár beérkezik a klienstől, hogy "OPTIONS *", erre a httpd konzultál a mod_jk-val, hogy az óhajt-e valamit kezdeni vele, a mod_jk meg elsősorban arra panaszol, hogy mit csináljon ő egy csillaggal, amikor eddig abban hitben élt, hogy ottan egy path-név jön, /perjellel kezdve.

Szerk: Mondjuk egy 'AllowMethods GET POST' valószínűleg segítene rajta...

Undefined symbol: .ap_proxy_balancer _get_best_worker

Azért szégyen, hogy megfosztom a szegény mod_lbmethod_byrequests.so-t a betevő ap_proxy_balancer_get_best_worker-től. Ez valószínűleg a httpd-2.4.34 újdonsága, mert eddig nem volt ilyen panasz.

20180719.1117: Annyit már látok, hogy a mod_proxy.so exportálja ezt a szimbóleumot.

subversion a korn shell ellen

subversion-1.10.0 fordítása során merült fel némi gond, ami végül ahhoz a kérdéshez vezetett el, hogy mit kellene csináljon ez a shell-utasítás:


echo "`Unused_variable=" $random_variable"`"

Ebben ott vélem a gondot látni, hogy a "macskakörmön" belül van a `backtick`, és azon belül van az újabb "macskaköröm". Mindenesetre nincs gond, ha ha `backtick` helyett $(cmd) van, vagy ha a belső macskakörmön belül nincs szóköz. Vagy ha a bash/dash/zsh shellt használunk.

Hány az óra, vekker úr?

Ugye ez nem száz százalékban jó:


$ date -d "1941-04-07 23:59:59" +%s  -906771601
$ date -d "1941-04-08 00:00:00" +%s  date: invalid date '1941-04-08 00:00:00'
$ date -d "1941-04-08 00:59:59" +%s  date: invalid date '1941-04-08 00:59:59'
$ date -d "1941-04-08 01:00:00" +%s  -906771600

Vagyis a derék szoftver szerint a tavaszi előrecsavarás miatt 23:59:59 után másnap 01:00:00 következett. Namostan ha nekem egy 'csak dátum' mezőm van, akkor azt általában 00:00:00 időponttal szoktuk teljes dátum+idővé alakítani, ami a (legalábbis ezen a gépemen) "nem létezett". Speciel a wiki nem ezt írja, de persze az sem jogforrás...

Hála Nyomasek Bobónak: explicit_memset

Ugyebár a mi Bobókánk mindenre képes, hogy segítsen nekünk, például kitalálta, hogy a compiler "kioptimalizálhatja" a memset-et. Namostan Bobó persze nem gondolhat mindenre (vagy bármire a saját kis perspektíváján kívül), tehát filmszínházunk bemutatja: explicit_memset

PHP-7.3 implementációja:


PHPAPI void php_explicit_bzero(void *dst, size_t siz)
{
...
#elif defined(__GNUC__)
        memset(dst, 0, siz);
        asm __volatile__("" :: "r"(dst) : "memory");
...
}

Ezt persze nem értem, de bizonyára jó, csak csavarnom kell egyet a gcc opcióin, pl s/-std=c99/-std=gnu99/g

libiconv-1.15

2018-04-18 14:03
Na jó, ez könnyű volt:

export AR="/usr/bin/ar -X32_64"

A rossz hír, hogy ezután sem tud EBCDIC-et (pl IBM037, IBM1047). Közben meg a linuxomon olyan iconv van, ami tud. Tehát az egy másik gyártó iconv-ja:


iconv --version
iconv (Debian GLIBC 2.19-18+deb8u10) 2.19
Copyright (C) 2014 Free Software Foundation, Inc.

ftp://ftp.software.ibm.com/software/globalization/gcoc/attachments/CP00…
ftp://ftp.software.ibm.com/software/globalization/gcoc/attachments/CP01…

2018-04-18 13:34
Na, mit találtam ki mára?


checking for ar... ar
checking the archiver (ar) interface... unknown
configure: error: could not determine ar interface

Notepad++ tabsize vs indentálás

Na, most túljárt az eszemen a szoftver: egyszerűen nem találok benne olyan opciót, hogy egyszerre csináljon két dolgot:

1. a TAB billentyűre menjen a következő 4k+1. pozícióra (értelmeszerűen szóközök beszúrásával; ha akarja, optimalizálja a szóközöket TAB karakterekkel, de a következő pont figyelmbevételével)

2. a TAB karakter hatására menjen a következő 8k+1. pozícióra

A korszerűtlen grafikátlan mcedit-ben ez az "Options / General / Tabulation / Fake half tabs" nevű feature.

Nem kell ám a felhasználónak mindent elhinni!

Botor fejjel belenéztem a php-2.7.4 'configure' futásának outputjába, ha azt írja nagy szomorúan, hogy nincs nekem 'curl_version_info'-m. De szerintem van, vagy a spájzban a befőttek között, vagy pedig a /usr/local/lib64/libcurl.so-ban.

De persze a 'configure' szuterén jogának tartja, hogy a CFLAGS/LDFLAGS-ot figyelembe vegye-e, vagy sem. Pont ebben az esetben nem vette figyelembe (bár a CPPFLAGS-ot igen), ezért megtalált valahol valami jó régi 32-bites libcurl.a-t, a default '-maix32' opciónak megfelelően.

Akkor most mi legyen? Tegyem bele a CPPFLAGS-ba is a '-maix64 -Wl,-brtl' opciókat? Az se rossz...

Hátétépé, rajtam kezdé -- httpd-2.4.33 nem fordul

Eddig szokott fordulni a httpd, dehát semmi sem tart örökké... Kellett neki újabb libcurl, azt tettem neki, de annak nincs köze ehhez a hibához


libtool: compile: gcc ... mod_proxy.c -o .libs/mod_proxy.o
mod_proxy.c:2675:1: error: unknown type name 'apr_OFN_ssl_engine_set_t'

mod_proxy.c:2675:1: error: unknown type name 'apr_OFN_ssl_engine_set_t'
 static APR_OPTIONAL_FN_TYPE(ssl_engine_set) *proxy_ssl_engine = NULL;
 ^
mod_proxy.c: In function 'ap_proxy_ssl_engine':

És igaza van: a cpp -dD nevű varázseszközzel megnézve sincs ilyen 'apr_OFN_ssl_engine_set_t' definiálva.