When you see the following kind of errors during cross compilation (linking phase):
ld: warning: libfontconfig.so.1, needed by …/libQtGui.so, not found (try using -rpath or -rpath-link)
ld: warning: libaudio.so.2, needed by …/libQtGui.so, not found (try using -rpath or -rpath-link)
There could be two reasons:
- the list of required binaries is not complete and linker cannot complete the linking automatically
- your $SYSROOT/usr/lib is not passed to linker by -rpath-link as mentioned in error message
During normal native build your libraries are stored in standard locations (/usr/lib) and locating libraries is easier. Cross compilation needs more attention in this ares as SYSROOT is not standard.
Then search for LDFLAGS setup in your build scripts:
And change to the following:
The clumsy syntax -Wl,<options-with-comma-as-space> tells your compiler (that is used for linking purposes) to pass the options (with commas replaced by spaces of course) to linker (ld).
Posted in en
If you encounter the following error during VPN connection:
pptp: nm-pptp-service-12543 warn[decaps_gre:pptp_gre.c:331]: short read (-1): Message too long
there's an easy fix. You have to lower your MTU (automatically obtained value was invalid).
First, you have to locate your VPN gateway address in syslog:
NetworkManager: <info> VPN Gateway: X.X.X.X
Then, you have to check minimum MTU toward this address:
$ traceroute –mtu X.X.X.X
traceroute to X.X.X.X (X.X.X.X), 30 hops max, 65000 byte packets
1 192.168.43.1 (192.168.43.1) 4.309 ms F=1380 4.042 ms 2.535 ms
2 * *^C
Then you have to change MTU it in your primary connection settings (network manager on Ubuntu below):
That's all!. No more spurious disconnects!
Posted in en
The best idea PR guys from PayU might have:
Dear Sir or Madam,
We would like to apologize for the INCORRECT INFORMATION in our last communication.
During the break which will take place on 27 November 2014 from 05:00 am to 05:30 am you could not be able to log in into the system but all transactions WILL BE SETTLED. A message informing about unavailability of the service may be displayed during login attempt.
We are very sorry for the inconvenience and misrepresentation.
The funny thing is that I haven't got any e-mail on the technical break in the first place.
Recently new vulnerability ("poodle") has been discovered in SSLv3 protocol. "man in the middle" attack could be performed using protocol version negotiation feature built into SSL/TLS to force the use of SSL 3.0 then exploit the "poodle" vulnerability.
In order to remove the threat from our servers we have to drop SSLv3 from negotiation list. Secured server should respond as follows:
$ echo | openssl s_client -connect 192.168.1.100:80 -ssl3 2>&1 | grep Secure
Secure Renegotiation IS NOT supported
$ echo | openssl s_client -connect 192.168.1.100:80 -tls1 2>&1 | grep Secure
Secure Renegotiation IS supported
We use openssl command to open HTTPS connection and check if requested protocol could be negotiated or not.
And the fix itself (for JBoss/Tomcat service): you have to locate Connector tag responsilble for HTTPS connection and:
- remove any SSL_* from ciphers attribute
- limit sslProtocols="TLSv1, TLSv1.1, TLSv1.2"
<Connector port="80" protocol="HTTP/1.1" SSLEnabled="true" ciphers="TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA"
maxThreads="100" scheme="https" secure="true" minSpareThreads="25" maxSpareThreads="50"
clientAuth="false" sslProtocols="TLSv1, TLSv1.1, TLSv1.2" />
It will effectively block any SSLv3 connections as visible by "openssl s_client" test above.
Posted in en