Tag: devel

Posted on

Oracle 11g 64 bit telepítése ubuntu 12.04 64 bit alá

Az Oracle céget és piacvezető alkalmazásukat elég jól jellemzi, hogy az ubuntu és minden más normális linux disztribúció támogatása kimerül abban, hogy tedd redhat-ra mert az a supportált. Oracle adatbázis miatt redhat-et telepíteni pedig több mint nevetséges.

Az ubuntura történő telepítés nem is olyan bonyolult, csak rá kell jönni a telepítő (és a borzasztó oracle telepítést végző script halom) működésére.

A telepítő két dolgot csinál valójában:

  1. kimásolja az oracle fájlokat
  2. sok make fájlal, és elképzelhetetlenül sok (és értelmetlen) változó segítségével lefordítja a bináris dolgokat

Az első lépésen viszonylag könnyen felül lehet emelkedni, a neten megvan hozzá minden, én csak kigyűjtöttem egy helyre.

Kell egy kevés dependencia, hogy egyáltalán elinduljon a telepítés:

sudo apt-get install ksh less lesstif2 lesstif2-dev lib32z1 libaio1 libaio-dev \
libc6-dev libc6-dev-i386 libc6-i386 libelf-dev libltdl-dev libmotif4 \
libodbcinstq4-1 libodbcinstq4-1:i386 libpth-dev libpthread-stubs0 \
libpthread-stubs0-dev lsb-cxx make openssh-server pdksh rlwrap rpm \
sysstat unixodbc unixodbc-dev unzip x11-utils zlibc gcc-multilib \
ia32-libs libstdc++5 libstdc++5:i386

Egy két extra link, hogy minden ott legyen, ahol a telepítő keresi:

sudo ln -s /usr/bin/basename /bin/basename
sudo ln -sf /bin/bash /bin/sh
sudo ln -s /usr/bin/rpm /bin/rpm
sudo ln -s /usr/bin/awk /bin/awk
sudo mkdir /usr/lib64
sudo ln -s /usr/lib/x86_64-linux-gnu/libc_nonshared.a /usr/lib64/
sudo ln -s /usr/lib/x86_64-linux-gnu/libpthread_nonshared.a /usr/lib64/
sudo ln -s /usr/lib/x86_64-linux-gnu/libstdc++.so.6 /usr/lib64/
sudo ln -s /lib/x86_64-linux-gnu/libgcc_s.so.1 /lib64
sudo ln -s /usr/lib/i386-linux-gnu/libpthread_nonshared.a /usr/lib/libpthread_nonshared.a
sudo ln -s /bin/lib/libgcc_s.so.1 /lib/libgcc_s.so
sudo ln -s /usr/lib/libstdc++.so.6.0.13 /usr/lib/libstdc++.so.5

Egy user, és pár group a telepítőnek, és az oracle példánynak:

 sudo groupadd oinstall
sudo groupadd dba
sudo groupadd nobody
sudo useradd -m oracle -g oinstall -G dba
sudo passwd oracle

Kell még egy pár kernel paraméter:

sudo nano /etc/sysctl.conf

Ide az alábbi dolgokat kell felvenni:

kernel.shmall = 2097152
kernel.shmmax = 2147483648
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
fs.file-max = 65536
net.ipv4.ip_local_port_range = 1024 65000

Ha a módosításokkal megvagyunk, olvastassuk fel újra a kernelparamétereket:

sudo /sbin/sysctl -p

A limits-eket is érdemes módosítani:

sudo nano /etc/security/limits.conf

ide fel kell még venni az alábbi sorokat:

* soft nproc 2047
* hard nproc 16384
* soft nofile 1024
* hard nofile 65536

És kell még egy ál-redhat release is, hogy a telepítő megnyugodjon:

sudo nano /etc/redhat-release

A fájl tartalma pedig:

Red Hat Enterprise Linux AS release 3 (Taroon)

Ha mindent default módon telepítünk, akkor érdemes még felvenni, az alábbi környezeti változókat, hogy az életünk könnyebb legyen már a telepítés alatt is:

#oracle exports
export ORACLE_BASE=/home/oracle
export ORACLE_HOME=$ORACLE_BASE/app/oracle/product/11.2.0/dbhome_1
export ORACLE_SID=orcl11
export PATH=$PATH:$ORACLE_HOME/bin

Ha ezzel megvagyunk, akkor jöhet a telepítő kitömörítése, és indítása (oracle userként).

xhost +
sudo su oracle
~/oracle_install/runInstaller

A fájlok másolása ha nem rontottunk el semmit, akkor hiba nélkül megtörténik, az érdekes rész ezután jön. Amikor elkezd fordítani az oracle, jó eséllyel látunk majd egy két hibát. Gondolom meg kell indokolni Oracle-nál, hogy mire kell azt a nagyon sok support költséget fizetni (hogy nem normális telepítő írására, az biztos). A hibák az alábbi főbb problémákra vezethetőek vissza:

  1. Ubuntu alatt a gcc picit szigorúbban fordít, és meg kell enyhíteni a lelkét, amin a „-Wl,–no-as-needed” paraéterpáros általában szokott segíteni.
  2. Hiányoznak a fordításhoz referenciák, amit a gcc általában –l(lib) formában kap meg.

Itt fontos megjegyezni, hogy a –lagtsh az valójában libagtsh.so-t jelent, azt érdemes keresni. Másik hasznos utasítás az nm parancs, aminek a segítségével megnézhetjük, hogy egy adott függvény, amit épp a make nem talál, milyen so fájlokban van benne. Pl:

nm -A $ORACLE_HOME/lib/*.so | grep procr_get_ctx

Ahol U van, ott az so fájl használja a szolgáltatást, ahol T ott implementálva van.

A neten sok problémára van megoldás, de nem mindre (én kettőre nem találtam). A tapasztalatom szerint ilyen esetekben érdemesebb picit beleásni a dolgokba, és megérteni, mit és miért csinálunk, mert az az esetek nagy részében célravezetőbb mint mindenféle misztikus sed-et, és egyéb utasításokat kiadni, hátha valami működik.

Az részletes fordítás alatt jelentkező (make) hibákat az alábbi módon érdemes nézni:

tail -f $ORACLE_HOME/install/make.log

Vegyük sorra, hogy nálam milyen problémák adódtak, és mi volt a megoldásuk:

– libagtsh.so: undefined reference to `nnfyboot’ in make: rdbms/lib/dg4odbc]

Ez egy elég ravasz hiba, a probléma az, hogy nincs még meg az a fájl, ami a fordításhoz szükséges. A megoldást az internet szállítja: fordítsunk magunknak egyet:

ln -s $ORACLE_HOME/lib/libclient11.a $ORACLE_HOME/lib/libagtsh.a
$ORACLE_HOME/bin/genagtsh $ORACLE_HOME/lib/libagtsh.so 1.0

 

– libnnz11.so: could not read symbols: Invalid operation /sysman/lib/ins_emagent.mk

Kis keresgetés után lehet látni, hogy a hívás a $ORACLE_HOME/sysman/lib/ins_emagent.mk fájlból indul, és egy olyan szolgáltatásra hivatkozik, ami a libnnz11.so-ben van benne. Ezt pótoljuk oly módon, hogy a dependenciát is kapja meg meg a gcc:

$ORACLE_HOME/sysman/lib/ins_emagent.mk

régi:

$(MK_EMAGENT_NMECTL)

új:

$(MK_EMAGENT_NMECTL) -lnnz11

– genorasdksh: Failed to link liborasdk.so.11.1

Szintén egy dependencia probléma, amikor a teljes oracle sdk-t próbálja lefordítani, akkor nagyon sok dolgot nem talál hirtelen. A megoldás hasonló az előző esethez, a megnézzük a szolgáltatásokat, azonnal feltűnik, hogy a libagtsh.so és a  liborasdkbase.so hiányzik neki nagyon. Értessük meg vele:

$ORACLE_HOME/bin/genorasdksh

Régi:

OLIBS="$LCLIENT $LSQL $LVSN $LNETWORK $LCLIENT \
$LCOMMON $LGENERIC $LMM $XAONDY $LNETWORK $LCLIENT $LCOMMON \
$LGENERIC $LTRACE $LNNET_ON $LSKGXP"

Új:

OLIBS="$LCLIENT $LSQL $LVSN $LNETWORK $LCLIENT \
$LCOMMON $LGENERIC $LMM $XAONDY $LNETWORK $LCLIENT $LCOMMON \
$LGENERIC $LTRACE $LNNET_ON $LSKGXP -lagtsh -lorasdkbase"

– getcrshome – libhashgen11 missing reference

Itt ha megnézzük, akkor az a szolgáltatás amit keres, megtalálható az .so fájlban, ami meg is van adva. Itt a hiányzó extra paraméter a gond. Kis keresgetés után erre is rá lehet találni. A megoldás:

$ORACLE_HOME/srvm/lib/env_srvm.mk

Régi:

LDOBJSZ=-m64

Új:

LDOBJSZ=-m64 -Wl,--no-as-needed

És láss csodát, hiba nélkül működik az oracle ubuntun. Szerencsére csak az oracle build script-jeit láttam, a forrását nem, de ha azt is olyanok írták, mint ezeket a scripteket, akkor jobb is ez így…

Posted on

Eclipse – Required projects on the build path

Nem tudom, hogy miért velem történik mindig az, hogy egy 5 perces dolog 1 óráig tud tartani. Valamiért az eclipse úgy döntött, hogy a Required projects on the build path opció beadja az unalmast, és nem működik. Végigtúrtam a fél internetet, kevés sikerrel… Amikor már kezdtem ráunni a dologra, csináltam egy új workspace-t, megnéztem, mit ír bele az eclipse a .classpath fájlba, és beleírtam kézzel:

<classpathentry combineaccessrules="false" kind="src" path="/cloudsync_common"/>

Close, open project és láss csodát, működik… pff…

A ma este tanúsága:
42067_019_Alternate2

Posted on

WordPress popup dialog

A wordpress pont olyan nekem a honlapoknál mint a lokalizáció a programoknál. Általában mindig úgy indul a dolog, hogy felesleges, ez csak egy egyszerű valami lesz, és a végére (mondjuk pár év fejlesztés után) kiderül, hogy mégis csak kell, és megkerülhetetlen. Személy szerint már a hello world honlapot is csak wordpress alá telepíteném, mert előbb utóbb biztos kiderül, hogy kellene bele még egy két dolog, és aztán meg lehet szívni a migrálással.

A wordpress önmagában is egy jó választás, minőségi átlátható kód, stb.

De mi is kell a jquery ui használatához? Egy plugin, aminek meglepő módon jQuery UI Widgets.

Ezek után már lehet standard módon használni a dialógus ablakot:

jQuery(document).ready( function(){
 jQuery('#blood_1').click(function() {
  jQuery('#blood_1_details').dialog({modal: true,title:'blood_1 details'});
 });
});

 

<a id="blood_1" href="#invalid">details</a>
<div id='blood_1_details' style='display:none;'>Game WASD+Mouse cfg...</div>

A javascriptet betölthetjük külön is a Specific CSS/JS for Posts and Pages plugin segítségével, és ha nem akarjuk ezeket a dolgokat hard code-olni az oldalunkba, akkor használhatjuk a php include-okat is az Exec-PHP plugin segítségével.

Posted on

Java, jpeg, exception

Az egyik publikus képfeltöltő szervlet kapcsán jeleztek egy hibát, hogy valamiféle csodaképeket egyszerűen nem lehet feltölteni. A naplófájlok elemzése után látszott is a hiba:

java.lang.IllegalArgumentException: Numbers of source Raster bands and source color space components do not match
 at java.awt.image.ColorConvertOp.filter(ColorConvertOp.java:460)
 at com.sun.imageio.plugins.jpeg.JPEGImageReader.acceptPixels(JPEGImageReader.java:1114)
 at com.sun.imageio.plugins.jpeg.JPEGImageReader.readImage(Native Method)
 at com.sun.imageio.plugins.jpeg.JPEGImageReader.readInternal(JPEGImageReader.java:1082)
 at com.sun.imageio.plugins.jpeg.JPEGImageReader.read(JPEGImageReader.java:897)
 at javax.imageio.ImageIO.read(ImageIO.java:1422)
 at javax.imageio.ImageIO.read(ImageIO.java:1282)

A hiba viszonylag könnyen reprodukálható volt, tehát volt egy jó képem, és egy rossz. A gimp semmi extrát nem mondott a képről, és a rossz kép az ismételt elmentés után is rossz maradt.

Kis keresgélés után rátaláltam az exiftool nevű alkalmazásra:

exiftool -a -G ./JUT430-1.jpg

Látszott is, hogy a kép adatai között mindenféle furcsaság található:

[JFIF] JFIF Version : 1.01
 [JFIF] Resolution Unit : inches
 [JFIF] X Resolution : 300
 [JFIF] Y Resolution : 300
 [ICC_Profile] Profile CMM Type : HDM
 [ICC_Profile] Profile Version : 2.4.0
 [ICC_Profile] Profile Class : Output Device Profile
 [ICC_Profile] Color Space Data : CMYK
 [ICC_Profile] Profile Connection Space : Lab
 ...
[ICC_Profile] Profile Description : ISO Coated v2 (ECI)
 [ICC_Profile] Char Target : (Binary data 126677 bytes, use -b option to extract)
 [EXIF] Modify Date : 2012:08:21 09:56:35
 [EXIF] Compression : JPEG (old-style)
 [EXIF] Thumbnail Offset : 1829717
 [EXIF] Thumbnail Length : 5947

Ekkor gyanús lett a dolog, az én képeimen nem volt ennyi szemét. Letöröltem az összes exif adatot:

exiftool -all= ./JUT430-1.jpg

A dolog működött, a kép megnyitható java-ban. Innen már azt hittem egyszerű a dolog, már csak meg kellene oldani, hogy az exif adatokat a java is le tudja kapni feldolgozás előtt.

Erre találtam is egy ígéretes projektet az Apache common’s Sanselan-t. Az mondjuk furcsa volt, hogy még incubator-os, béta, és 3 éve senki nem nyúlt hozzá, de abból indultam ki, hogy biztosan azért mert annyira jó… 🙂

Természetesen a dolog nem működött. A forráskód tanulmányozása során feltűnt, hogy az általam használt kódból mintha hiányzott volna az érdemi rész…

</pre>
public void removeExifMetadata(ByteSource byteSource, OutputStream os)
 throws ImageReadException, IOException, ImageWriteException
 {
 JFIFPieces jfifPieces = analyzeJFIF(byteSource);
 List pieces = jfifPieces.pieces;

//Debug.debug("pieces", pieces);

//pieces.removeAll(jfifPieces.exifPieces);

//Debug.debug("pieces", pieces);

writeSegmentsReplacingExif(os, pieces, null);
 }
<pre>

Gondoltam ez így nem a legjobb, ezért visszacommenteztem (nyílt forráskód rulz) a removeAll-t. Sajnos ez még önmagában nem jelentett megoldást, ugyanis nem minden addicionális adat EXIF adat, és pont azok az adatok maradtak a képen, amik a problémát okozták.

Minden JFIFPieceSegment eltávolítása nem minősült kimondottan jó taktikának, de egy kis wikipedia-s utánaolvasás után megvolt, hogy mik az egyéb adatok marker bit-jei, amikre nekem semmi szükségem, innen már csak pár sor választott el a sikertől…


public void removeExifAndAllMetadata(ByteSource byteSource, OutputStream os)
 throws ImageReadException, IOException, ImageWriteException
 {
 JFIFPieces jfifPieces = analyzeJFIF(byteSource);
 List pieces = jfifPieces.pieces;

//Debug.debug("pieces", pieces);

 Iterator it = pieces.iterator();

 while (it.hasNext()) {
   Object object = (Object) it.next();
   if (object instanceof JFIFPieceSegment ) {
     JFIFPieceSegment iffdat=(JFIFPieceSegment)object;
     if (iffdat.marker>= 0xFFE0 && iffdat.marker<=0xFFEF) {
        it.remove();
     }
   }
 }

 pieces.removeAll(jfifPieces.exifPieces);

//Debug.debug("pieces", pieces);

writeSegmentsReplacingExif(os, pieces, null);
 }

A végeredmény valami ilyesmi lett:

public static void main(String[] args) {
 try {
String fileName="c:/JUT430-1.jpg";
File f=new File(fileName);
ExifRewriterAdv eRewriter=new ExifRewriterAdv();
FileInputStream fis=new FileInputStream(f);
ByteSourceInputStream bis=new ByteSourceInputStream(fis, null);
ByteArrayOutputStream bout=new ByteArrayOutputStream ();
eRewriter.removeExifAndAllMetadata(bis, bout);
ByteArrayInputStream iobis=new ByteArrayInputStream(bout.toByteArray());
ImageIO.read(iobis);
 } catch (Exception e) {
e.printStackTrace();
 }
 }
Posted on

Diablo 3

Nem hittem volna, hogy valaha ezt fogom mondani (kiálltam érte, védtem), de ha valaki azt tervezi, hogy diablo 3-at vesz, írja inkább be a böngészőjébe:

http://error37.com

Olcsóbb, az élmény pedig ugyanaz.

A blizzard meg egy szánalom. Komolyan.

Posted on

SyncToCloud.net

Nagy nehezen elindult végre a synctocloud.net.
Mint minden jó release esetén az utolsó pillanatokban még hibákat javítottam (egész pontosabban próbáltam megcsinálni azokat a dolgokat, amikről már azt hittem, hogy rég megcsináltam őket).
És mint minden jó program esetében itt sem az a kérdés, hogy van e benne hiba, inkább csak az, hogy mennyi 🙂

Posted on

Eclipse Class cache

Az új eclipse verzió óta elég gyakran megesik velem, hogy egy két projektben egyszerűen nem működik az auto-import, open by type, és ehhez hasonló nyalánkságok.

Erre a megoldás egyszerű, törölni kell a workspace/.metadata/.plugins/org.eclipse.jdt.core könyvtárból a *.index and savedIndexNames.txt fájlokat…

Posted on

Excel open in new window

Az egész világ Jobs haláláról beszél (ma a zite-ba nem találtam olyan topicot, amiben a 10 cikkből legalább 7 ne erről szólt volna). Én pedig még mindig a miocrosoft ördögi találmányaival harcolok. Nem tudom ki találta ki, hogy az excel nem tud azonos nevű fájlt megnyitni (hiába más a fájl elérése), és nem lehet két excel ablakot KÜLÖN használni… De az ilyen embert legalább egy kirúgással kellene jutalmazni.

Persze mint mindent, ezt is át lehet állítani, igazán minőségi eredeti windowsos ablakokban (amik még a windows 95-ből maradtak fenn), amit nem lehet nagyítani, így egy bélyeg méretű helyen kell átpörgetni a több ezer ismert kiterjesztést, egy olyan listában ahol se csoportosítva nincs semmi, és még keresni se lehet…

És aki ezt mind végigcsinálja, egy idő után azt tapasztalja, hogy bizonyos alkalmazások (telepítése, vagy működése, vagy csak a véletlen folyamán), az egész eltűnik, és csinálhatja meg újra.

Én is ezt csináltam minden windowson, néha működött, néha nem, egészen addig amíg meg nem untam és ma nem kerestem picit tovább. Gondoltam csak másnak is eszébe jutott ami nekem.

És nem meglepő módon igen: http://www.bitterminion.com/excel-instance-launcher/

Jól indult a napom, adtam is nekik 10 dollárt, mert megérdemlik.