Centos 7.x - Minimal network setup

This is a continuation of a previous post, but this time dedicated to CentOS 7 (our customer is evolving!!)

Environment:

• Virtualbox 5.1.10
• CentOS 7.4.1708

Before start with the installation, in Virtualbox you have to configure two network adapters:

• Adapter 1: Host only
• Adapter 2: NAT

The first one will be used to communicate host and guest, for example, by using a ssh connection. The second one will be used by the guest in order to gain direct access to the internet.

When CentOS starts for first time, you will already had internet access. But local network will be disabled. Execute the following command to check your network interfaces:

ip add

The result will be something like this:

Here you can see three interfaces:

• lo: Loopback
• enp0s3: Host-Only adapter
• enp0s8: NAT adapter

If you have doubts about which is the host-only, you can check the MAC address and compare it with the Virtualbox adapter.

Once you are sure enp0s3 is your interface, go to /etc/sysconfig/network-scripts/ and edit ifcfg-enp0s3 file, for example with vi. You will have to make two changes:

• Set BOOTPROTO=none
• Set ONBOOT=yes
• Add IPADDR=your IP

Then execute the following command:

systemctl restart network.service

Now you will have your interface up and with the IP address you set before.

Note

As stated in my previous post, remember to configure proxy settings for system and yum configuration:

System config

Edit ~/.bash_profile file and add the following lines:

# The Web proxy server used by this account
http_proxy="http://usuario:password@my.proxy:8080"

export no_proxy=localhost,127.0.0.1
export http_proxy

YUM config

Edit  /etc/yum.conf y add the following lines:

# The proxy server - proxy server:port number
proxy=http://my.proxy:8080
# The account details for yum connections
proxy_username=usuario
proxy_password=password




LibreOffice - Force PDF/A export

I was using LibreOffice to convert documents from disparate formats to PDF. This is done by using the following command:

libreoffice5.3 --headless --convert-to pdf prueba.txt

My problem was that the output file was not int PDF/A format.

LibreOffice, by working with it´s GUI interface, do supports PDF/A conversion, so the problem should be in some kind of default configuration.

There is configuration file called registrymodifications.xcu which contains all settings used by the programa, and during the exportation too. This file is located in  ~/.config/libreoffice/4/user/ directory. For example /root/.config/libreoffice/4/user/registrymodifications.xcu.

This is an xml based file with a lot of (poor/undocumented) preferences. In particular, in order to set PDF/A as default option, you have to insert the following config line:

<?xml version="1.0" encoding="UTF-8"?>
<oor:items xmlns:oor="http://openoffice.org/2001/registry" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 (...)
 <item oor:path="/org.openoffice.Office.Common/Filter/PDF/Export">
  <prop oor:name="SelectPdfVersion" oor:op="fuse">
   <value>1</value>
  </prop>
 </item>
 (...)
</oor:items>

Now, if you launch the conversion again you will get a PDF/A-1A file.

Though registrymodifications.xcu file is quite obscure, you can get mor info by using the GUI version of the program. If you navigate to Tools > Options > LibreOffice > Advanced > Open Expert Configuration, you can check the whole list of settings.

Unix - CIFS / NFS Mount

Mount CIFS

fstab:

//host/server_dir /mnt/unix_dir  cifs gid=jboss,uid=jboss,domain=xxxxx,user=yyyyy,password=zzzzz,_netdev,rw   0 0

Mount NFS

fstab:

host:/server_dir /mnt/unix_dir nfs rsize=8192,timeo=14,intr 0 0

HTTP response '413: Request Entity Too Large' when communicating with 'xxx'

I was able to reproduce this error with Apache 2.2 + mod_ssl.

Just configure a virtual host port 443 and set the SSLVerifyClient to required or optional.

<Location />
    SSLRequireSSL 
    SSLOptions +StdEnvVars +ExportCertData +StrictRequire
    SSLVerifyClient optional
    SSLVerifyDepth 2   
</Location>

When you send a large request, for example a SOAP message which contains a file (bad practice, use MTOM), you could get the following error:

[2017-12-07 16:59:42,313] (LogUtils.java:478) WARN main org.apache.cxf.phase.PhaseInterceptorChain Interceptor for {http:/xxxxxxxxxxxxxxxx}yyyyyyyyy#{http:/xxxxxxxxxxxxxxxx}generarCSV has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: Could not send Message.
 at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:64)
 at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
 at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:518)
 at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:427)
 at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:328)
 at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:281)
 at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
 at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:139)
 at com.sun.proxy.$Proxy22.generarCSV(Unknown Source)
 at es.sisifo.cxf.client.SinaturaServiceClient.run(SinaturaServiceClient.java:81)
 at es.sisifo.cxf.client.SinaturaServiceClient.main(SinaturaServiceClient.java:93)
Caused by: org.apache.cxf.transport.http.HTTPException: HTTP response '413: Request Entity Too Large' when communicating with https://my-service-endpoint
 at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.doProcessResponseCode(HTTPConduit.java:1609)
 at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1616)
 at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1560)
 at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1361)
 at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
 at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:658)
 at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
 ... 10 more

The solution is to use the SSLRenegBufferSize directive:

If an SSL renegotiation is required in per-location context, for example, any use of SSLVerifyClient in a Directory or Location block, then mod_ssl must buffer any HTTP request body into memory until the new SSL handshake can be performed. This directive can be used to set the amount of memory that will be used for this buffer.

This buffer is referred to the whole size of the request, i.e, if you are sending a 200KB file, then the value should be set to around 250000 (you have to spare some size for the rest of the request).

<Location />
    SSLRequireSSL 
    SSLOptions +StdEnvVars +ExportCertData +StrictRequire
    SSLVerifyClient optional
    SSLVerifyDepth 2
    SSLRenegBufferSize 250000 
</Location>

In other places you can also found that the problem could be solved with other two directives, LimitXMLRequestBody  and LimitRequestBody but I was not able to reproduce my problem by using them.