prism.js

2024. május 29., szerda

VPN hálózatról jövő IP névfeloldása Docker konténerben (Ubuntu)

Elsősorban Linux rendszereken volt észlelhető az a probléma, hogy lokális gép (Linux, Ubuntu) ha Dockert futtat, Dockeren belül nem látható vagy DNS feloldható a VPN-ből jött címek. A hibát a systemd-resolved okozza a linux-os kornyezetekben. Tegyük fel hogy az alap docker telepítés nem lett átírva és a resolved a 127.0.0.53-as címen halgatózik és a docker a 172.17.0.0/12 címtartományt használja. Más esetben a megfelelő címeket kell használni. Telepiteni kell a socat csomagot
sudo apt install socat
Létre kell hozni egy service definíciós file-t.
sudo cat /etc/systemd/system/docker-dns.service
[Unit]
Description=Docker DNS bridge
After=docker.service
Requires=docker.service

[Service]
Type=simple
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=docker-dns-bridge

ExecStart=socat -d -d UDP-LISTEN:53,reuseaddr,fork,bind=172.17.0.1 UDP:127.0.0.53:53
Restart=always

[Install]
WantedBy=multi-user.target

Ezután újraindítani amit kell:
sudo systemctl daemon-reload
sudo systemctl start docker-dns.service
sudo systemctl enable docker-dns.service

Valamint a dockernek is meg kell mondani hogy a megfelelő DNS szervert használja
sudo cat /etc/docker/daemon.json
{
"dns": ["172.17.0.1"]
}

Valamint még újra kell indítani a docker service-t
sudo systemctl restart docker

Az ezután létrehozott konténerekben már jól fog működni a VPN-en keresztüli belső címek feloldása Megeshet hogy a rendszerben van firewall ami még mindig blokkolhat, mint ahogy az Ubuntuban van alapértelmezett "ufw". Ezesetben a következő parancsot kell futtatni:
ufw allow in on docker0 to any port 53 proto udp

UFW tűzfal howto
# A tűzfal státuszának lekérdezése
ufw status numbered
# egy port engélyezese a docker0 interfészről
ufw allow in on docker0 to any port 53 proto udp
# ugyanennek az engedélynek az eltávolítása
ufw delete allow in on docker0 to any port 53 proto udp
# az egész tűzfal kikapcsolása
ufw disable
# az egész tűzfal bekapcsolása
ufw enable

2014. március 4., kedd

Hibernate SQL logging = jBoss 7 + log4jdbc + JNDI + JPA + logback

Maga a JPA nem teszi lehetővé a pontos adatbázis felé történő kommunikációt, csak annyit amennyit a persistence.xml fájban állíthatunk:
<persistence version="2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/persistence" xsi:schemalocation="
        http://java.sun.com/xml/ns/persistence
        http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">

    <persistence-unit name="primary" transaction-type="JTA">
        <provider>org.hibernate.ejb.HibernatePersistence</provider>

        <jta-data-source>java:/jdbc/primary</jta-data-source>

        <properties>
            <property name="hibernate.dialect" value="org.hibernate.dialect.Oracle10gDialect"></property>
            <property name="hibernate.hbm2ddl.auto" value="none"></property>
            <property name="hibernate.show_sql" value="false"></property>
            <property name="hibernate.format_sql" value="true"></property>
            <property name="hibernate.transaction.manager_lookup_class" value="org.hibernate.transaction.JBossTransactionManagerLookup"></property>
            <property name="hibernate.connection.release_mode" value="auto"></property>

            <property name="hibernate.transaction.jta.platform" value="org.hibernate.service.jta.platform.internal.JBossAppServerJtaPlatform"></property>

        </properties>
    </persistence-unit>
</persistence>
Ez sok esetben nem elegendő, mert nem látszódnak a felhasznált paraméterek, visszatérő értékek és típusai, stb...
Erre nagyon nagyon jó szolgálhat a log4jdbc. Ha a projektünket jBoss-ban definiált JNDI datasource-kkal használjuk akkor a kódunk érintettlen maradhat, nem kell hozzárakni semmi csomagot és konfigot.
Elősször is le kell szedni a log4jdbc oldalról a jar fájlt, és bele rakni a jBoss modules közé (létrehozzuk az útvonalat és bemásoljuk a jar fájlt és létrehozzuk a module.xml fájlt):
<module name="com.googlecode.log4jdbc" xmlns="urn:jboss:module:1.1">
  <resources>
    <resource-root path="log4jdbc4-1.2.jar">
  </resource-root></resources>

    <dependencies>
    <module name="org.slf4j"></module>
    <module name="javax.api"></module>
    <module name="javax.transaction.api"></module>
    <module name="com.oracle"></module>
    </dependencies>
</module>
A kiemelt sorba olyan adatbázis dependencia kell, melyet használunk. Az én esetemben ez Oracle.
Most a jBoss standalone.xml-ben kell aktiválni a log4jdbc-t:
<server xmlns="urn:jboss:domain:1.2">
    <extensions>...</extensions>
    <system-properties>
        <property name="logback.configurationFile" value="c:/logback.xml">
        <property name="log4jdbc.drivers" value="oracle.jdbc.OracleDriver">
        <property name="log4jdbc.auto.load.popular.drivers" value="false">
    </property></property></property></system-properties>
    <management>...</management>
    <profile>...
        <subsystem xmlns="urn:jboss:domain:datasources:1.0">
            <datasources>
                <datasource enabled="true" jndi-name="java:/jdbc/primary" jta="true" use-ccm="true">
                    <connection-url>jdbc:oracle:thin:@//192.168.1.100:1521/DB</connection-url>
                    <driver>oracle</driver>
                </datasource>
                <drivers>
                    <driver module="com.oracle" name="oracle">
                        <driver-class>oracle.jdbc.OracleDriver</driver-class>
                        <xa-datasource-class>oracle.jdbc.OracleDriver</xa-datasource-class>
                    </driver>
                </drivers>
            </datasources>
        </subsystem>
        ...
    </profile>
    ...
</server>
<server xmlns="urn:jboss:domain:1.2">
    <extensions>...</extensions>
    <system-properties>
        <property name="logback.configurationFile" value="c:/logback.xml">
        <property name="log4jdbc.drivers" value="oracle.jdbc.OracleDriver">
        <property name="log4jdbc.auto.load.popular.drivers" value="false">
    </property></property></property></system-properties>
    <management>...</management>
    <profile>
        ...
        <subsystem xmlns="urn:jboss:domain:datasources:1.0">
            <datasources>
                <datasource enabled="true" jndi-name="java:/jdbc/primary" jta="true" use-ccm="true">
                    <connection-url>jdbc:log4jdbc:oracle:thin:@//192.168.1.100:1521/DB</connection-url>
                    <driver>log4jdbc</driver>
                </datasource>
                <drivers>
                    <driver module="com.oracle" name="oracle">
                        <driver-class>oracle.jdbc.OracleDriver</driver-class>
                        <xa-datasource-class>oracle.jdbc.OracleDriver</xa-datasource-class>
                    </driver>
                    <driver module="com.googlecode.log4jdbc" name="log4jdbc">
                        <driver-class>net.sf.log4jdbc.DriverSpy</driver-class>
                    </driver>
                </drivers>
            </datasources>
        </subsystem>
        ...
    </profile>
    ...
</server>
Mostmár csak a loggolás beállítása maradt hátra. Az én esetemben logback van használva, external konfig fájból, így az applikáció teljesen érintetlen a JDBC aktiválásától:
<configuration debug="true" scan="true">

  <appender class="ch.qos.logback.core.ConsoleAppender" name="STDOUT">
    <encoder>
      <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
    </encoder>
  </appender>

  <!-- log4jdbc sql & jdbc logging -->
  <logger additivity="false" name="jdbc.sqlonly">
    <level value="INFO">
  <appender-ref ref="STDOUT">
  </appender-ref></level></logger>
  <logger additivity="false" name="jdbc.sqltiming">
    <level value="INFO">
  <appender-ref ref="STDOUT">
  </appender-ref></level></logger>
  <logger additivity="false" name="jdbc.audit">
    <level value="INFO">
  <appender-ref ref="STDOUT">
  </appender-ref></level></logger>
  <logger additivity="false" name="jdbc.resultset">
    <level value="INFO">
  <appender-ref ref="STDOUT">
  </appender-ref></level></logger>
  <logger additivity="false" name="jdbc.connection">
    <level value="INFO">
  <appender-ref ref="STDOUT">
  </appender-ref></level></logger>
  <logger additivity="false" name="log4jdbc.debug">
    <level value="DEBUG">
  <appender-ref ref="STDOUT">
  </appender-ref></level></logger>

 <root level="trace">
  <appender-ref ref="STDOUT">
 </appender-ref></root>

</configuration>
Itt egy hasonló példa http://sfleiter.github.io/blog/2013/12/08/jboss-datasource-proxy-with-log4jdbc-log4j2/

2014. február 20., csütörtök

TestNG + @ArquillianResteasyResource method parameter -> org.testng.TestNGException

Az arquillian-rest-client példái mind JUnit-al vannak elkészítve, viszont ha valaki TestNG-vel akarja használni a tesztet, akkor a következő exception-t kaphat, hogyha @Test metódusban paramétert akar rakni:
org.testng.TestNGException: 
Method callAccountRest requires 1 parameters but 0 were supplied in the @Test annotation.
 at org.testng.internal.Parameters.checkParameterTypes(Parameters.java:198)
 at org.testng.internal.Parameters.createParameters(Parameters.java:134)
 at org.testng.internal.Parameters.createParameters(Parameters.java:373)
 at org.testng.internal.Parameters.handleParameters(Parameters.java:450)
 at org.testng.internal.Invoker.handleParameters(Invoker.java:1383)
 at org.testng.internal.Invoker.createParameters(Invoker.java:1075)
 at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1180)
 at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
 at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
 at org.testng.TestRunner.privateRun(TestRunner.java:767)
 at org.testng.TestRunner.run(TestRunner.java:617)
 at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
 at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
 at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
 at org.testng.SuiteRunner.run(SuiteRunner.java:240)
 at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
 at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
 at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
 at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
 at org.testng.TestNG.run(TestNG.java:1057)
 at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:111)
 at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:204)
 at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:175)
Ennek a megoldása itt ARQ-562 található, de nem könnyű elsőre rátalálni.

Szóval a megoldás:
Path: "\src\test\java"
import org.jboss.arquillian.extension.rest.client.ArquillianResteasyResource;
import org.jboss.arquillian.testng.Arquillian;
import org.testng.annotations.Test;

public class TestNGExampleIT extends Arquillian {

    @Test(dataProvider = Arquillian.ARQUILLIAN_DATA_PROVIDER)
    public void test(@ArquillianResteasyResource InputParam param) {
        //...
    }
}

import org.jboss.arquillian.junit.Arquillian;
import org.jboss.arquillian.test.api.ArquillianResource;
import org.junit.Test;
import org.junit.runner.RunWith;

@RunWith(Arquillian.class)
public class JUnitExampleIT {

   @Test
   public void test(@ArquillianResteasyResource InputParam param) {
      //...
   }
}
Imi

prism.js

VPN hálózatról jövő IP névfeloldása Docker konténerben (Ubuntu)

Elsősorban Linux rendszereken volt észlelhető az a probléma, hogy lokális gép (Linux, Ubuntu) ha Dockert futtat, Dockeren belül nem látható ...