Linux + Glassfish 4.0 High availability Load Balancing Cluster – osa 3

Viime kerroille rakensimme Glassfish servereistä klusterin, joka voisi elää vaikka virtuaalikoneissa tai Amazonin palveluissa. Pistimme sen eteen Apache Http-palvelimesta rakennetun Load Balancer ratkaisun – josta kannattaa myös tehdä High Availability ratkaisu, eli pistää niitäkin useampi kopio käyttöön. Vielä pitäisi saada aikaan se, että jos yksi Load Balancer kaatuu, muut ottavat sen paikan. Sitä pohdimme tällä kertaa.

Ideana on viritellä keepalived-niminen daemon ohjelma siten, että sille annetaan yksi yhteinen jaettu virtuaalinen ip-osoite. Keepalived reitittää sen ensisijaisesti ykköskoneelle, mutta jos se kaatuu, kakkoskone ottaa virtuaalisen ip:n haltuunsa. Näin ollen elleivät kaikki load balancerit kaadu yhtäaikaa, palvelun pitäisi pyöriä lähes katkotta.

Tässä esimerkissä virtuaalinen ip-osoite on 192.168.1.100, ja sen takana olevien koneiden todelliset ip-osoitteet voivat olla vaikkapa 192.168.1.101, 102, 103, jne – niitä ei tässä esimerkissä käytetä, vaan koneiden domain nimiä, jotka ovat edelleen debian1, debian2, jne.

Ensin asenna keepalived joka nodelle:

sudo apt-get install keepalived

Seuraavaksi editoi keepalived konfiguraatiota – sitä ei alussa ole ollenkaan, joten aloitetaan tyhjästä:

sudo nano /etc/keepalived/keepalived.conf

Ensimmäiselle koneelle, joka on oletuksena master, kopioi tiedostoon jotain tämäntapaista:

vrrp_script chk_http_port {   # Requires keepalived-1.1.13

script "wget -q -T 1.0 -t 2 --delete-after -O /tmp/test.wget http://localhost:80/index.html"

interval 5            # check every 5 seconds

weight 2              # add 2 points of prio if OK

}

vrrp_instance VI_1 {

interface eth0

state MASTER          # MASTER debian1, BACKUP debian2

virtual_router_id 51  # same id in both hosts

priority 101          # 101 on master, 100 on backup

virtual_ipaddress {

192.168.1.100         # virtual IP

}

track_script {

chk_http_port

}

}

 

Ja kakkoskoneelle modifioidaan tuota vähän, tähän tapaan:

 

vrrp_script chk_http_port {   # Requires keepalived-1.1.13

script "wget -q -T 1.0 -t 2 --delete-after -O /tmp/test.wget http://localhost:80/index.html"

interval 5            # check every 5 seconds

weight 2              # add 2 points of prio if OK

}

vrrp_instance VI_1 {

interface eth0

state BACKUP          # MASTER debian1, BACKUP debian2

virtual_router_id 51  # same id in both hosts

priority 100          # 101 on master, 100 on backup

virtual_ipaddress {

192.168.1.100         # virtual IP

}

track_script {

chk_http_port

}

}

 

Eli muuten sama, mutta prioriteetti vähän pienempi, ja tilana tosiaan BACKUP. Toki sovelletaan sen mukaan onko verkkokortti eth0, ja löytyykö serverin juuresta index.html tiedosto jolla voi testata vastaako serveri, miten tiheään haluat pollailla, jne.

Mutta viiden sekunnin välein siis testataan löytyykö index.html tiedostoa – jos ei, serverin prioriteetti nousee kahdella. Eli jos molemmat serverit ovat pystyssä, debian1 prioriteetti on 101+2 eli 103, ja debian2 on 100+2 eli 102, eli debian1 saa virtuaalisen ip-osoitteen. Jos ykkösserveri kaatuu, sen prioriteetti laskee 101+0, eli 101, ja näin debian2 saa virtuaalisen ip-osoitteen.

Lopuksi potkaistaan keepalived käyntiin ja testataan:

sudo service keepalived start

Ota yhteyttä selaimella virtuaaliseen ip-osoitteeseen – voit testata suoraan aiemmin käytettyä clusterjsp-sovellusta:

http://192.168.1.100/clusterjsp

Toimiiko? Hyvä. Oletuksena kytkeydyit varmaankin debian1 koneeseen, sekä apache että glassfish instanssiin. Seuraavaksi voitaisiin nitistää debian1 koneen glassfish:

sudo service glassfish-inst stop

Toimiiko? Hyvä, en olisi uskonut. Debian1 koneen apache ohjaa kuorman debian2 koneen glassfish serverille. Nitistetään seuraavaksi debian1 koneen apache:

sudo service apache2 stop

Kokeile vielä kerran virtuaali-ip:tä. Nyt sen pitäisi ohjata debian2 koneen apachelle, joka ohjaa debian2-koneen glassfishille.

Jos ei toimi, mokasit. Savun hälvettyä tarkista kytkennät ja yritä.uudestaan. Paljon on säätöjä näissä. Mutta metkasti toimii 😉 Kannattaa vielä buutata palvelimet ja katsoa että kaikki pelaa edelleen.

 

No niin, ja tässä pari kuvaruutukaappausta high availabilitystä toiminnassa. Olen hieman retusoinut serverinimiä ja ip osoitteita suojellakseni alkuperäisten tietokonehenkien identiteettiä ja persoonaa julkisuudelta, mutta näistä käy idea selväksi:

HAClient_1

Eli sessioon on pumpattu vähän dataa, tässä välissä kävin Glassfish konsolissa nitistämässä debian1 instanssin.

HAClient_2

Ja heittämällä mentiin kakkosnodelle, sessio data replikoituneena verkon yli ja edelleen käytettävissä ilman käyttäjälle näkyvää katkosta. Samoin voisi nitistää kumman hyvänsä load balancerin, tai vaikka vetää töpselin seinästä koko koneesta.

 

Nyt kun saisi vielä tietokantakerroksen vikasietoiseksi ja kuormaa tasaavaksi…..

Mainokset

Linux + Glassfish 4.0 High availability Load Balancing Cluster – osa 2

Viime kerralla viritettiin kaksi Glassfish serveriä juttelemaan keskenään – ja tarvittaessa replikoimaan istunnotkin. Tällä kertaa laitetaan niiden eteen Apache Http serveri LoadBalanceriksi. LoadBalancerin tehtävänä on ohjata liikenne toimiville servereille ja ohittaa vikatilassa tai sammuneina olevat – sekä tasata kuormaa serverien välillä. Näitäkin kannattaa tehdä ainakin kaksi kappaletta – yksi joka instanssikoneeseen – koska muuten loadbalancer on uusi kriittinen pisteesi – heikoin lenkki.

Aloitin ensin MOD_JK:lla, koska se on load balancer vaihtoehdoista ’javamaisempi’, joka tarkoittaa että se osaa tehdä monenmoisia temppuja mitä muut eivät osaa, mm. ssl-salauksen, monitoroinnin ja dynaamisten säätöjen suhteen. Valitettavasti testatessa paljastui, että vaikka se toimi hienosti clusterjsp esimerkille, se antoi suurikokoisilla tiedostoilla mehukkaita Grizzly-poikkeuksia (mm. HeapBuffer has already been disposed). Tämä on ilmeisesti Glassfish 4.0 bugi – en ollut ainoa joka tästä kärsi. Kenties 4.1 korjaa tämän – 4.0:han on tarkoituskin olla high availability early access versio. Mutta kärsimätön mieli ei jaksa eikä pysty odottamaan. Joten tein ratkaisun mod_proxyllä. Listaan kuitenkin testatut mod_jk käyttöönotto-ohjeet tähän samaan artikkeliin – loppuun. Mutta ensin mod_proxy ja toimiva versio:

MOD_PROXY Load balancer asennusohjeet

Ohjeissa oletetaan että koneet joihin asennat nämä ovat nimeltään debian1 ja debian2, ja asennat kaiken joka koneelle.

Aloita asentamalla ja aktivoimalla tarvittavat moduulit:

sudo apt-get install apache2 libapache2-mod-proxy-html libxml2-dev

sudo a2enmod proxy proxy_http proxy_balancer rewrite

Testaa käynnistyykö apache2:

sudo service apache2 start

Jos kaikki hyvin, seuraavaksi editoi tiedostoa /etc/apache2/sites-available/default lempieditorillasi. Sen voisi muokata esim. tämän näköiseksi (muista muokata se klusterin kaikille koneille, ja vastaavasti muutaa host name osia, jotta load balanceristä on kopioita):

<VirtualHost *:80>
 ServerName debian1.mycompany.com
 ServerAdmin webmaster@localhost

 ErrorLog ${APACHE_LOG_DIR}/error.log

 # Possible values include: debug, info, notice, warn, error, crit,
 # alert, emerg.
 LogLevel warn

 CustomLog ${APACHE_LOG_DIR}/access.log combined

 RewriteEngine On
 ProxyRequests Off
 ProxyPreserveHost On

 <Proxy *>
 Order deny,allow
 Allow from all
 </Proxy>

 <Location /balancer-manager>
 SetHandler balancer-manager
 Order Allow,Deny
 Allow from all
 # Only allow from internal network
 #Allow from 10.0.0.0/8
 </Location>

 <Proxy balancer://mycluster>
 BalancerMember http://debian1:8080 route=debian1
 BalancerMember http://debian2:8080 route=debian2
 ProxySet lbmethod=byrequests
 </Proxy>

 ProxyPass /balancer-manager !
 ProxyPass / balancer://mycluster/ stickysession=JSESSIONID
 ProxyPassReverse / http://debian1:8080/
 ProxyPassReverse / http://debian2:8080/

</VirtualHost>

Käynnistä apache uudelleen, ja kokeile ohjata selaimesi load balancer-koneen osoitteeseen. Sen pitäisi ohjata vuoronperään eri myllyille – voit testata tätä vaikkapa avaamalla pari eri selainta, tai sammuttamalla ykkösmyllyn. Proxypasseja voi tietysti lisätä ja muokata sen mukaan mitä kaikkia kansioita haluat uudelleenohjata ja miten. Load balancer algoritmejakin löytyy useampia.

No niin, seuraavaksi vaihtoehtoiset ohjeet mod_jk versiolle. Sitä en itse päätynyt käyttämään, mutta se voi olla testaamisen arvoinen Glassfish 4.1 kanssa aikanaan.

MOD_JK load balancer asennusohjeet

Aloita asentamalla softat kaikille haluamillesi koneille:

sudo apt-get install apache2 libapache2-mod-jk

Voisit tässä kohtaa editoida tiedostoa /etc/apache2/mods-available/jk.conf  – mutta siellä ei ole mitään pakollista muutettavaa, joten mennään sensijaan suoraan editoimaan toista tiedostoa:

sudo nano /etc/libapache2-mod-jk/workers.properties

Editoi tätä tiedostoa, voit kommentoida pois esim. oletus-jk13 workerin säätöjä, mutta muuta yksi riveistä tällaiseksi:

worker.list=loadbalancer,jk-status

Ja lisää tämätapaista (jos laitteita on enemmän kuin kaksi, lisää rivejä vain – tietysti sovella verkkonimet jne):

worker.debian1.port=8009
worker.debian1.host=debian1.mycompany.com
worker.debian1.type=ajp13
worker.debian1.lbfactor=1
worker.debian2.port=8009
worker.debian2.host= debian2.mycompany.com
worker.debian2.type=ajp13
worker.debian2.lbfactor=1
worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=debian1,debian2
worker.loadbalancer.sticky_session=1
worker.jk-status.type=status

Huomaa miten voit load balance factoreilla esim. painottaa miten kutsuja jaetaan. Tässä on käytössä sticky_session joka ei ole välttämätöntä. Olemme jättäneet myös status-tiedot päälle. Huomaa että jk moduuli myös kirjoittelee logia oletuksena paikkaan /var/log/apache2/mod_jk.log – logit on hyvä tarkastaa aika ajoin näitä testatessa.

Hommaa alkaa olla melkein valmis. Seuraavaksi editoidaan apache serverin omaa oletuskonfiguraatiota, ja lisätään kaikki halutut hakemistot joita halutaan uudelleenohjata:

sudo nano /etc/apache2/sites-available/default

Ja konfiguraatio voi mennä esim. näin:

<Location /jk-status>
 # Inside Location we can omit the URL in JkMount
 JkMount jk-status
 #Order deny,allow
 #Deny from all
 #Allow from 127.0.0.1
 </Location>

# mount clusterjsp
 JkMount /clusterjsp loadbalancer
 JkMount /clusterjsp/* loadbalancer

Nämä tulevat tietysti kaikki juurielementin VirtualHost sisään, loppuun, ja jos haluat lisää hakemistoja loadbalanceriin clusterjsp:n lisäksi, määrittele ne kaikki tähän.

Seuraavaksi enabloidaan mod_jk (luultavasti jo päällä), buutataan apache, ja aletaan kokeilemaan:

sudo a2enmod jk
sudo /etc/init.d/apache2 restart

Näppärä testi on ensin avata selain osoitteeseen http://debian1/clusterjsp – ja katsoa aukeaako sovellus. Apache pyörii portissa 80 – glassfishit porteissa 8080 omissa koneissaan. Jos sovellus toimii, näet miltä serveriltä se on noudettu. Nyt voit mennä glassfish hallintaan (DAS) ja sammuttaa instanssin joka on käytössä. Jos load balancer toimii oikein, sen pitäisi seuraavan kerran sivua päivitettäessä saumattomasti pompauttaa sinut toiselle instanssille.

Muista tehdä tämä load balancer molempiin/kaikkiin instansseihin niin voimme seuraavalla kertaa rakentaa siitäkin high availability version. Koska mitä jos Load Balancer kaatuu?

 

 

Java 8 + Glassfish 4 asennus Debian Linuxiin – osa 2

Viimeksi asenneltiin Debianiin glassfishiä. Tässä pari edistynyttä niksiä:

32-bit kirjastot 64-bit debianiin

64-bit debian ei välttämättä suostu ajelemaan pkg työkalua jolla voi päivitykset tehdä – se valittaa ia32-libs paketista ja pythonista. Ongelma: kun yrität asentaa paketin, se valittaa riippuvuuksista joita ei olekaan. Ratkaisu tässä:

sudo dpkg --add-architecture i386
sudo apt-get update
sudo apt-get install libjpeg62:i386
sudo apt-get install ia32-libs

Nice.

Glassfish asennuksen päivittäminen ajan tasalle.

Nyt voit päivitellä lasikalan uusimpiin kirjastoihin pkg työkalulla esim. näin:

#stop Glassfish
sudo service GlassFish_domain1 stop

# Switch to being user 'glassfish'
sudo su --shell /bin/bash glassfish 

/opt/glassfish4/bin/pkg -R /opt/glassfish4 list
/opt/glassfish4/bin/pkg -R /opt/glassfish4 image-update -v

exit # Revert to being old caffeine-deprived yourself

Muista ajaa kaikki tiedostoja luovat komennot kuten päivitykset ja käynnistykset glassfish-tunnuksella. Jos teet jotain muulla, voit korjata tilanteen päivittelemällä omistajuudet taas glassfish-kansioon ja/tai poistamalla esim. tilapäistiedostot ja cachet. Näin saat omistajuudet kuntoon:

sudo chown glassfish:glassfish -R /opt/glassfish4

 

Oletuksena zip-versio Glassfish ei omaa etähallintaa ja sen admin-salasana on tyhjä, ja master-salasana ’changeit’ – eli ei kovin käyttökelpoinen eikä turvallinen. Korjataanpa nämä.

Glassfish työkalut polkuun

Jatko-operaatioita ajatellen on kätevää lisätä Glassfish bin kansio polkuun, jotta pääset työkaluihin suoraan käsiksi. Tässä vinkit siihen:

#run these as glassfish to generate right ownerships for files
sudo su --shell /bin/bash glassfish

#These will help running the tools:
cd ~
nano .bashrc

#Set up environment for user 'glassfish': edit .bashrc and add this to end:

export PATH="${PATH}":/opt/glassfish4/glassfish/bin

# save file in editor

Testaa voitko ajaa komennon: asadmin. Ellei, kirjaudu ulos ja sisään.

Glassfish master password

Master password on tosiaan oletuksena: changeit – joten muutetaanpa se. Valitettava seuraus on, että muutos päivittää myös avain-ja sertifikaattitiedostoja, joten on taas oltava omistajuuksien kanssa tarkkana. Tässä ohjeistusta:

#if you're glassfish user, exit back to your normal user:
exit

#make sure glassfish is stopped
sudo service GlassFish_domain1 stop

#run these as glassfish to generate right ownerships for files
sudo su --shell /bin/bash glassfish

#Backup default passwords, if you got already master-password file, backup it too:
cd /opt/glassfish4/glassfish

tar cf passwords.orig.tar domains/domain1/config/domain-passwords domains/domain1/config/keystore.jks domains/domain1/config/cacerts.jks

Tässä kohtaa on olemassa varmuuskopio passwords.orig.tar josta löytyy alkuperäiset tiedostot. Nyt muutetaan niitä:

Change master password
asadmin change-master-password --savemasterpassword=true domain1
# Enter the current master password> [By default this is 'changeit']
# Enter the new master password> [e.g. 'Y0uW1llN3v3rGu3ssTh1sL33tP4ssw0rd!']
# Enter the new master password again>
# After entering the new master password twice, there is a pause of several
# seconds. Then you will find new versions of 'master-password'
# 'domain-passwords' 'keystore.jks' and 'cacerts.jks'.

Sitten kokeillaan toimiiko homma – nämä komennot kysyvät salasanaa, anna siihen valitsemasi master password.

# Your chosen master password should unlock both keystores, and reveal
# two certificates in keystore.jks, and many additional ones in cacerts.jks.
keytool -list -v -keystore domains/domain1/config/keystore.jks 
keytool -list -v -keystore domains/domain1/config/cacerts.jks

Ja jos meni jotain pieleen, aina on varmuuskopiot. Toivottavasti ne menivät oikein alunperin, kai tarkistit ne? 😉 Jos kaikki ok, näin voit palauttaa tarvittaessa alkuperäiset tiedostot jos jotain meni pahasti pieleen:

#if you mess up, you can return the backups by going to /opt/glassfish4/glassfish and running: tar -xvf passwords.orig.tar

 Admin-salasana ja etähallinnan aktivointi

Oletuksena tosiaan admin-salasana on tyhjä, ja etähallinta disabloituna. Näin saat korjattua nämä puutteet:

#exit to normal account, sudo start server - it needs to be running
exit
sudo service GlassFish_domain1 start
sudo su --shell /bin/bash glassfish

# enable remote administration for glassfish 

asadmin enable-secure-admin

# ja tässä kohtaa syytä buutata taas palvelin jotta asetukset
# astuvat voimaan

exit
sudo service GlassFish_domain1 restart
sudo su --shell /bin/bash glassfish

Nyt on tilaisuus tallettaa nämä tiedot paikallisesti, siten että linux-tunnuksiltasi ei salasanaa kysellä:

########Store admin password, to enable automatic login to localhost:4848
asadmin login
# Enter admin user name [Enter to accept default]> [Just press Enter]
# Enter admin password> [e.g. whatever you selected earlier]
# Login information relevant to admin user name [admin] for host [localhost] and admin port [4848] stored at [/home/glassfish/.gfclient/pass] successfully.
# Make sure that this file remains protected. Information stored in this file will be used by administration commands to manage associated domain.
# Command login executed successfully.

Eli, tämän tiedoston voit kopioida haluamiesi linux-tunnusten kotihakemiston alle, .gfclient/pass kansioon. Sen oikeudet voit muuttaa niin että vain user omaa oikeudet päästä tähän käsiksi. Muista säätää myös omistajuus oikein, eli omistajaksi ko tunnus.

Voit myös tuikata admin-konsolin vain https-protokollalle:

#Enable https for remote access to admin console
# Requests to http://xxx:4848 are redirected to https://xxx:4848

asadmin set server-config.network-config.protocols.protocol.admin-listener.security-enabled=true

Glassfish käyttämään portteja 80 ja 443 – ilman root oikeuksia

Jos haluat Glassfishin operoivan porteissa 80 ja 443 – mutta et halua ajaa sitä root tunnuksin jotka normaalisti vaaditaan ko porttien käyttöön  – voit tehdä /etc/init.d/GlassFish_domain1 tiedoston loppuun seuraavat reititykset – näin nämä ajetaan root tunnarilla, mutta itse glassfish normaalisti glassfish tunnarilla – ja portit 80 ja 443 ovat käytössä.

iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8080
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8181

 Sertifikaatit uusiksi

Glassfish oletussertifikaatit ovat tasan samat mitä jokainen käyttää – ei kovin turvallista. Tässä ohjeita miten voit tehdä uudet avaimet omaan käyttöön:

# Ensure that you are running as user 'glassfish'!!
# Ensure GlassFish is stopped

#Inspect keystore.jks
cd /opt/glassfish4/glassfish/domains/domain1/config/
keytool -list -keystore keystore.jks -storepass [whateverismymasterpassword]

#Update keystore.jks

keytool -delete -alias s1as -keystore keystore.jks -storepass [whateverismymasterpassword]

keytool -delete -alias glassfish-instance -keystore keystore.jks -storepass [whateverismymasterpassword]

keytool -genkeypair -alias s1as -dname "CN=myservername,OU=myunit,O=MyOrganization,L=MyTown,C=FI" -keyalg RSA -keysize 2048 -validity 3650 -keystore keystore.jks -keypass [whateverismymasterpassword] -storepass [whateverismymasterpassword]

keytool -genkeypair -alias glassfish-instance -dname "CN=myservername,OU=myunit,O=MyOrganization,L=MyTown,C=FI" -keyalg RSA -keysize 2048 -validity 3650 -keystore keystore.jks -keypass [whateverismymasterpassword] -storepass [whateverismymasterpassword]

#Check keystore.jks

keytool -list -keystore keystore.jks -storepass [whateverismymasterpassword]

#Export certificates from keystore.jks

keytool -exportcert -alias s1as -file s1as.cert -keystore keystore.jks -storepass [whateverismymasterpassword]

keytool -exportcert -alias glassfish-instance -file glassfish-instance.cert -keystore keystore.jks -storepass [whateverismymasterpassword]

#Update cacerts.jks

keytool -delete -alias s1as -keystore cacerts.jks -storepass [whateverismymasterpassword]

keytool -delete -alias glassfish-instance -keystore cacerts.jks -storepass [whateverismymasterpassword]

keytool -importcert -alias s1as -file s1as.cert -keystore cacerts.jks -storepass [whateverismymasterpassword]

#Trust this certificate? [no]: [Enter 'yes']

keytool -importcert -alias glassfish-instance -file glassfish-instance.cert -keystore cacerts.jks -storepass [whateverismymasterpassword]

#Trust this certificate? [no]: [Enter 'yes']

#Check cacerts.jks and tidy up

keytool -list -keystore cacerts.jks -storepass [whateverismymasterpassword]

rm s1as.cert glassfish-instance.cert

exit

Done! Nyt on uudet ja omat avaimet serverillä, ja aiemman vaiheen ansiosta uudella master salasanalla suojattuna. Tässä voi välivaiheena allekirjoituttaa sertifikaattinsa jollain virallisella taholla jos haluaa tuotantokäyttöön sopivan vimpaimen.

Serveriheaderien obfuskointi – äläpä kerro enempää!

Yksi oma lempiaiheeni tietoturvassa on ollut suojata systeemeitä siten että ne eivät kerro tarpeettoman paljon itsestään .- esim. header joka sanoo: X-Powered-By: Servlet/3.1 JSP/2.3 (GlassFish Server Open Source Edition 4.0 Java/Oracle Corporation/1.7) – suorastaan kirkuu googlettamaan seuraavaksi haavoittuvuuksia, oletustunnuksia, ja täsmähyökkäysohjelmia. Mitä vähemmän paljastaa tietoa ulospäin sen vaikeampaa on heti tietää mitä hyökkäyksiä soveltaa. Vielä kierompaa on näyttää misinformaatiota – esim. ajaa IIS palvelinta joka väittää olevansa Glassfish tai Glassfishiä joka väittää olevansa Websphere jne.

Tässä komennot joilla voit tukahduttaa näitä headereita. Huom! Ne muuttavat domain1/config/domain.xml tiedostoa, joten syytä taas olla glassfish tunnuksena sisässä (komento whoami kertoo mikä on tunnuksesi). Glassfish serverin tulee olla päällä.

#start glassfish if it's not running
sudo service GlassFish_domain1 start

#Ensure that you are running as user 'glassfish'!!
sudo su --shell /bin/bash glassfish

#Check HTTP headers
# Check HTTP response headers (as shown below) to make sure that there are
# clues as to the server or its version. Look for any mention of
# 'GlassFish', 'X-Powered-By', etc. If necessary:

asadmin create-jvm-options -Dproduct.name=

asadmin set server.network-config.protocols.protocol.http-listener-1.http.xpowered-by=false

asadmin set server.network-config.protocols.protocol.http-listener-2.http.xpowered-by=false

asadmin set server.network-config.protocols.protocol.admin-listener.http.xpowered-by=false

Samalla voit myös tsekata virhesivut, esim. 404 sivua ei löydy kertoo usein paljonkin serveristä. Se on muutenkin hyvä ottaa omaan haltuun. Voit tehdä tämän toki sovelluskohtaisenakin, mutta tässä on serverikohtainen asetus:

asadmin set server.http-service.virtual-server.server.property.send-error_1="code=404 path=/opt/glassfish4/glassfish/globalhtml/404.html reason=Resource_not_found"

Tämä menee domain.xml:ään – jota toki voi käsinkin muokata. Muillekin virheilmoituksille voi tehdä vastaavia. Saatat myös haluta disabloida/poistaa/vaihtaa juuri-kontekstin oletussivun ja sovelluksen.

Lopuksi tietysti buutataan mylly

#Restart to take effect

exit

sudo service GlassFish_domain1 restart

Virtuaalikoneen säädöt ja muisti

Virtuaalikoneen tuunaus on ihan oma taiteenlajinsa – sitä voi harrastaa web-admin konsolista, tai domain.xml tiedostoa editoimalla, mutta onnistuu se komentoriviltäkin:

#List current JVM options

asadmin list-jvm-options

# Now update some important JVM settings. 
# Of course use memory as you need to, so if you like 64GB max heap, go for it!

asadmin delete-jvm-options -Xmx512m
asadmin create-jvm-options -Xmx2048m
asadmin create-jvm-options -Xms1024m

# and run with -client or -server optimizations
# -client boots up faster, server optimizes tighter on longer run
# -client is now the default, so if you like -server:

asadmin delete-jvm-options -client
asadmin create-jvm-options -server

Siinä kaikki tällä erää. Moderni sovelluspalvelin on sillä tavalla kiehtova paketti että se sisältää hurjasti piirteitä, palveluita, ja yksityiskohtia. Monet näistä periaatteista pätevät hyvinkin muihinkin servereihin, kuten Tomcat ja JBOSS, ja miksei myös WebSphere/Weblogic. Toivottavasti näistä on apua.

 

Java 8 + Glassfish 4 asennus Debian Linuxiin – osa 1

Ajattelin kirjailla kokemuksia Glassfish Linux asennuksesta, 64-bittiseen Debianiin. Osaan 1 laitan perusohjeistusta, osaan 2 tulee sudenkuoppia ja yksityiskohtia.

Olen kirjoitellut jo aiemmin tästä Raspberry Pi vinkkelistä, mutta tässä vähän lisää yksityiskohtia. Tarinaa olen haalinut hyvistä muista blogeista, ja pistän linkkiä loppuun, mutta ainakin paras niistä on häviämässä netistä joten pistän tämän itsellekin talteen.

Testailin juuri asennuksia AWS pilvipalvelun 64-bittiseen Ubuntuun, ja näyttäisi pelittävän ihan heittämällä myös sinne.

Alkuun tarvitaan Java, JDK 7 tai 8, itsellä tietenkin 8. Tästä taisin juuri kirjailla, miten Java on lisenssiteknisistä syistä vähän jännä asennella. Mutta tässä Oracle JDK 8 litaniat:

#make sure you're up-to-date
sudo apt-get update
sudo apt-get upgrade

#install oracle jdk 8
sudo echo "deb http://ppa.launchpad.net/webupd8team/java/ubuntu trusty main" | sudo tee /etc/apt/sources.list.d/webupd8team-java.list
sudo echo "deb-src http://ppa.launchpad.net/webupd8team/java/ubuntu trusty main" | sudo tee -a /etc/apt/sources.list.d/webupd8team-java.list
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys EEA14886
sudo apt-get update
sudo apt-get install oracle-java8-installer
java -version

Löytyykö sieltä Java? Hienoa!

Glassfish oletusasennus käyttelee root tunnaria joka on vähän hyi hyi. Tämän vuoksi meidän kannattaa tehdä prosessille uusi käyttäjätunnus, glassfish. Jos lähdet tälle polulle, muista että muokatessa glassfish kansion tiedostoja tai ajaessa prosessia, se tulisi aina tehdä glassfish tunnarien alla. Muuten voi syntyä tiedostoja joihin glassfish-serveriprosessi ei omaa pääsyä, esim. temp, cache, jne. Sen voi onneksi aina korjata chownaamalla koko glassfish hierarkian.

#Add a new user called 'glassfish' with group 'glassfish'
sudo adduser --system --group --home /home/glassfish [--shell /bin/bash] glassfish
#Enable an existing user to be a GlassFish administrator. Repeat for additional users.
sudo usermod -a -G glassfish existingUserAccountName
# can check your groups with:
groups #list should include 'glassfish' - remember to relogin here!

Sitten tuikataan Glassfish 4 zip release paikalleen:

#get glassfish 4 release
cd ~
wget http://download.java.net/glassfish/4.0/release/glassfish-4.0.zip

sudo apt-get install unzip
sudo unzip -d /opt/ glassfish-4.0.zip 

#glassfish is owner of this folder
sudo chown -R glassfish:glassfish /opt/glassfish4
#glassfish can freely access bin folders and autodeploy
sudo chmod -R ug+rw /opt/glassfish4
#glassfish can execute binaries
sudo chmod -R ug+rwx /opt/glassfish4/bin
sudo chmod -R ug+rwx /opt/glassfish4/glassfish/bin
#others are not allowed to access glassfish
sudo chmod -R o-rwx /opt/glassfish4/

Seuraavaksi fiksataan proaktiivisesti yksi asia: Java seiskan viimeisimmissä päivityksissä – ja myös Java 8:ssa – on tiukennettu tietoturva-asetuksia. Tästä johtuen esim. Derby tietokantaa ei saa käyntiin ellei sitä salli policyissä. Tässä on karu tapa lisätä kaikelle ajettavalle Java-koodille oikeus käyttää Derby-porttia. Tätä voi tiukentaa halutessaan esim. kansiokohtaiseksi:

#edit $JAVA_HOME/jre/lib/security/java.policy, insert following between existing grant blocks:
grant {
 // allows Derby to claim port 1527
 permission java.net.SocketPermission "localhost:1527", "listen,resolve";
};

Seuraavaksi päräytetään vaihtaen glassfish tunnarille – jotta luotavat tiedostot menevät oikeille omistussuhteille ja oikeuksille. Käynnistetään derby ja glassfish jotta voidaan todeta toimiiko kaikki:

#now, run glassfish server & database
sudo su --shell /bin/bash glassfish
whoami # should say 'glassfish'
/opt/glassfish4/bin/asadmin start-database
/opt/glassfish4/bin/asadmin start-domain domain1

Kaikki hyvin? Voit testata varmuudeksi löytääkö selain portit:

http://localhost:8080

https://localhost:8181

http://localhost:4848

Jos näyttää hyvältä, on aika sammutella Glassfish, ja poistua glassfish tunnuksesta takaisin omaan:

/opt/glassfish4/bin/asadmin stop-domain domain1
/opt/glassfish4/bin/asadmin stop-database
exit

Jos kaikki löytyy, voit seuraavaksi asentaa tämän palveluna. Aloitetaan Glassfishin omalla työkalulla:

sudo /opt/glassfish4/bin/asadmin create-service

Valitettavasti käynnistysscripti jonka tämä luo on täyttä moskaa. Jos käynnistäisit nyt koneen, se ei toimisi. Siinä on monia virheitä:
– init.d scriptit ajetaan ennenkuin esim. profile tiedostot ja niiden pathit on käsitelty. Näin mitään työkaluja ei ole patheissa vaan pathit pitää exportoida erikseen, tai viitata koko absoluuttisilla poluilla
– scriptistä puuttuu service header tiedostot jotka estävät sen toiminnan
– oletusscripti ajelee serveriä roottina, joten jos sinne pujahtaa pätkä ilkeämmän puoleista koodia jonkun haavoittuvuuden vuoksi…. WORLD DOMINATION!!!
– derby kanta olisi myös hyvä käynnistellä ja sammutella
– olisi kiva saada status tietoja

Joten, korvataan scripti parannetulla versiolla. Avaa editori:

sudo nano /etc/init.d/GlassFish_domain1

Jyrää vanha moska tällä, säädä tarpeen mukaan vastaamaan omia polkujasi tai tarpeitasi:

#! /bin/sh
### BEGIN INIT INFO
# Provides: glassfish
# Required-Start: $remote_fs $network $syslog
# Required-Stop: $remote_fs $network $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Starts GlassFish
# Description: Starts GlassFish application server
### END INIT INFO
# We need this, since NetworkServerControl uses $JAVA_HOME to find java
export JAVA_HOME="/usr/lib/jvm/java-8-oracle"
GLASSFISH=/opt/glassfish4
DERBY_BIN=/opt/glassfish4/javadb/bin
case "$1" in
start)
 echo "Starting GlassFish from $GLASSFISH"
 sudo -u glassfish -E "$GLASSFISH/bin/asadmin" start-database
 sudo -u glassfish -E "$GLASSFISH/bin/asadmin" start-domain domain1
 ;;
stop)
 echo "Stopping GlassFish from $GLASSFISH"
 sudo -u glassfish -E "$GLASSFISH/bin/asadmin" stop-domain domain1
 sudo -u glassfish -E "$GLASSFISH/bin/asadmin" stop-database
 ;;
restart)
 $0 stop
 $0 start
 ;;
status)
 echo "# GlassFish at $GLASSFISH:"
 sudo -u glassfish -E "$GLASSFISH/bin/asadmin" list-domains | grep -v Command
 sudo -u glassfish -E "$GLASSFISH/bin/asadmin" list-domains | grep -q "domain1 running"
 if [ $? -eq 0 ]; then
 sudo -u glassfish -E "$GLASSFISH/bin/asadmin" uptime | grep -v Command
 echo "\n# Deployed applications:"
 sudo -u glassfish -E "$GLASSFISH/bin/asadmin" list-applications --long=true --resources | grep -v Command echo "\n# JDBC resources:"
 sudo -u glassfish -E "$GLASSFISH/bin/asadmin" list-jdbc-resources | grep "jdbc/"
 fi
 echo "\n# Derby:"
 sudo -u glassfish -E "$DERBY_BIN/NetworkServerControl" ping | sed "s/^.* : //"
 ;;
*)
 echo "Usage: $0 {start|stop|restart|status}"
 exit 1
 ;;
esac
exit 0

Nättiä kuin kesäheinän teko. Tässä voi olla vielä parannettavaa mutta itselle ainakin varsin tyydyttävä toiminta. Pistä kommenttia jos tulee parannuksia itsellesi mieleen!

Aja seuraavaksi palvelun testi:

#test that it works:
/etc/init.d/GlassFish_domain1 start
/etc/init.d/GlassFish_domain1 status
/etc/init.d/GlassFish_domain1 stop

Jup, status voi heittää vähän autentikointivirheitä koska kannassa ei ole glassfish käyttäjää. Mutta palvelun pitäisi käynnistyä ja sammua tätä kautta. Seuraavaksi uudelleenasennetaan tämä palveluna, ja testataan että se toimii edelleen:

#cool, now let's update the autorun part with the script:
sudo update-rc.d GlassFish_domain1 defaults

#test that it works as a service
sudo service GlassFish_domain1 start

#if it seems to work, test that it REALLY works: 
sudo reboot

#and verify by connecting to http://thisservername:8080 and http://thisservername:4848

Nice? Yeah, hyvin pelittää. Ensi kerralla voitaisiin näperrellä servosta turvallisempi ja tehokkaampi.

Linuxin kanssa on kiva pitkästä aikaa puuhailla. Niissä servereissä on erona winkku servoihin että kun johonkin ei koske pitkään aikaan ja sen melkein unohtaa, se toimii yhtä hienosti kuin asennuspäivänä 😉

Linkkivinkki mitä itse eniten käytin: http://www.physics.usyd.edu.au/~rennie/glassfish.html

Oracle Java 8 Debianiin

Jep jep, lisenssiyhteensopivuusongelmista johtuen Oraclen virallinen Java 8 on hieman mutkatonta hankalampaa saada Debianiin. Samoin Java 7. Vaihtoehto on toki asentaa OpenJDK. Mutta sattuneesta syystä törmäsin artikkeliin jossa neuvotaan miten myös Oracle Java 8 on asennettavissa – sekä JRE että JDK.

Jippo on tässä:

su -
echo "deb http://ppa.launchpad.net/webupd8team/java/ubuntu trusty main" | tee /etc/apt/sources.list.d/webupd8team-java.list
echo "deb-src http://ppa.launchpad.net/webupd8team/java/ubuntu trusty main" | tee -a /etc/apt/sources.list.d/webupd8team-java.list
apt-key adv --keyserver keyserver.ubuntu.com --recv-keys EEA14886
apt-get update
apt-get install oracle-java8-installer
exit

Jep, ei sen kummempaa.Tietysti voit myös pistää sudo komennon joka komentosarjan alkuun.

Jippo on siinä että repositorystä ei löydy varsinaisesti Java 8 versiota – vaan vain installer. Kun sen asentaa ja ajaa, tulee lisenssiehtojen hyväksyntädialogi. Ja sitten tippuu varsinainen Java.

Ja tietysti tarkistetaan mikä Java on kyseessä komennolla:

java -version

Tähän asennukseen sisältyy tietysti myös automaattiset päivitykset.

Vinkin lähde:

http://www.webupd8.org/2014/03/how-to-install-oracle-java-8-in-debian.html