P.Péter's questions

I have a Spring Boot application running currently under Tomcat 8.5 that has a shibboleth-based SSO integrated. Shibboleth and tomcat are connected using apache2 mod_shib and mod_jk, using default Debian 9 packages.

I am now trying to upgrade the application's environment to Debian 10 (and thus tomcat 9), and most things work with minor configuration changes, except the Shibboleth-based authentication.

If calling on /login/shibboleth (which is configured in apache to authenticate using shibboleth, and then login inside the application using the provided shibboleth shared variables), the shibboleth SAML2 authentication protocol is correctly done (and the shibboleth session can be queried after in apache), but the handler method for /login/shibboleth is not called (I checked this using remote debugging), but is refused by tomcat itself:

HTTP Status 403 – Forbidden
Type Status Report

Description The server understood the request but refuses to authorize it.

Apache Tomcat/9.0.31 (Debian)

I have tried to look into this problem, and one possible solution seemed to be using a secret in the AJP connector. Defining one (in tomcat9's server.xml) does not seem to change any behaviour (also, mod_jk does not seem to have a corresponding option, so I wonder how any function works when a secret is configured).

Does anyone have ideas about:

• What may cause this problem.
• What the possible solutions are.

If I try to access our HTTPS server that has certbot-issued certificate from debian 9, I get the following error:

 # curl -v https://hu.dbpedia.org/
 *   Trying 195.111.2.82...
 * TCP_NODELAY set
 * Connected to hu.dbpedia.org (195.111.2.82) port 443      (#0)
 * ALPN, offering h2
 * ALPN, offering http/1.1
 * Cipher selection:      ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
 * successfully set certificate verify locations:
 *   CAfile: /etc/ssl/certs/ca-certificates.crt
   CApath: /etc/ssl/certs
 * TLSv1.2 (OUT), TLS header, Certificate Status (22):
 * TLSv1.2 (OUT), TLS handshake, Client hello (1):
 * TLSv1.2 (IN), TLS handshake, Server hello (2):
 * TLSv1.2 (IN), TLS handshake, Certificate (11):
 * TLSv1.2 (OUT), TLS alert, Server hello (2):
 * SSL certificate problem: certificate has expired
 * Curl_http_done: called premature == 1
 * stopped the pause stream!
 * Closing connection 0
 curl: (60) SSL certificate problem: certificate has expired

However, if I try the same command from debian 10, it succeeds.

I tried to simply copy all ca-certificates from a debian 10 VM to the debian 9 VM (to /usr/local/share/ca-certificates) with rsync, and then ran update-ca-certificates which seemingly added 400+ certificates. Unfortunately, it did not help. This is no wonder, as it seems that there are the same certificates on both debian 9 and 10, apparently.

My question is: How can I access sites with certbot certificates from debian 9 machines without ignoring certificate verification altogether

We have a group of VMs that are configured using ansible, including basic zabbix monitoring using the zabbix_host module using a predefined zabbix template.

I would like to be able to generate web scenarios for each of the VMs that have web services. Ansible already has most relevant data e.g. fqdn of the web services. However, I do not see if this is possible using the current ansible zabbix collection.

Currently, the simplest possibility seems to be to compile the json to be sent to the zabbix API from a jinja2 template locally and then posting that manually using the url module (if possible, I am not sure it is fully-featured to create zabbix api POSTs) or with curl using the shell module.

Is there a better/more systematic way to create zabbix web scenarios using ansible?

I use a zabbix 2.2.7 to monitor our servers. I mostly use zabbix-agent with active checks as many of the monitored machines are behind NAT.

One of the checks on all linux servers is net.tcp.service[smtp] (used as active agent check), and it works on all servers but one. Other net.tcp.service active checks work on the server just fine. The monitored server runs exim4 (stock debian buster), and can receive and send e-mails just fine.

I enabled debugging for the given zabbix-agent, and this is the most informative line I got from it:

28545:20200204:103404.692 for key [net.tcp.service[smtp]] received value [0]

Which is not informative at all. :(

One anomaly I can detect is that if I telnet into exim, it gives the greeting line really slowly (about 15s).

My questions are:

• How can I debug what the zabbix-agent does during the net.tcp.service[smtp] check?
• How can I change the behaviour of that check?

EDIT: The problem really was the slowness of the server, which was caused by a bad primary DNS (it took that many seconds to start to use the secondary). However, my questions still stand, as it would have been much easier to debug if I could have just got the info that the check timed out in 5 seconds.

When I try to create an nfs-based persistent volume in our local kubernetes cluster, I get the following error:

# kubectl create -f nfs.yaml
error: error validating "nfs.yaml": error validating data: the server could not find the requested resource; if you choose to ignore these errors, turn validation off with --validate=false

The nfs.yaml has the following content:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-nfs-pv1
  labels:
    type: nfs
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteMany
  nfs:
    server: 192.168.1.3
    path: "/srv/kubedata/"

The kubernetes cluster runs on three virtual machines created in our local openstack cloud (installed with kubespray). The nfs share is on the first node, and could be mounted manually on all nodes.

How can I fix this problem? Is the problem in the yaml file? How can I diagnose the problem? It would be very helpful to know where exactly the error is: is there a debug mode for kubectl?

Update: The original yaml I posted was corrupt, but that was because the stack overflow quote algorithm ate some newlines. I fixed that, now the posted yaml seems to validate on https://kubeyaml.com/, so the yaml seems to be okay (syntax-wise, at least).

Update2:

# kubectl version
Client Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.0", GitCommit:"fff5156092b56e6bd60fff75aad4dc9de6b6ef37", GitTreeState:"clean", BuildDate:"2017-03-28T16:36:33Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.3", GitCommit:"2d3c76f9091b6bec110a5e63777c332469e0cba2", GitTreeState:"clean", BuildDate:"2019-08-19T11:05:50Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}

I would like to use haproxy (1.7.5-2 2017/05/17, debian stretch stock) as a first line of defense against some possible attacks (e.g. SQL injection). The idea is that I create an acl in the frontend that detects unwanted patterns using regexps and then use an always-failing dummy backend in that case. Something like this:

acl sql_injection url_reg -i -f /etc/haproxy/sqlinject.patterns
use_backend bad_request if sql_injection                                                                            

The problem is, that if the url is url-encoded, then e.g. foo.com/?select foo from bar would be transmitted as foo.com/?select%20 foo%20from%20bar, which really needs a different regexp, and thus a matching regexp would bee unnecessarily broad. Hence come url_dec:

acl sql_injection url_reg,url_dec -i -f /etc/haproxy/sqlinject.patterns

However, this does not seems to work, as it does not seem to match anything. Even if I put .* into the pattern file, I get no matches.

There is no syntactical error in the configuration, as haproxy -c returns no warnings or errors. How could I match the urldecoded query string?

I have a machine that handles multiple virtual domains. Some of these include aliases defined for those specific domains (domain names will be changed from real names).

I have, for example:

$ cat /etc/exim4/virtual/alias.domain.com
hibak: "|/usr/local/bin/mail2redmine.sh blah"

And, of course alias.domain.com is included in dc_other_hostnames in /etc/exim4/update-exim4.conf.conf.

It worked fine on debian jessie, but after upgrading to stretch, the virtual hostnames ceased to work. Getting a letter for them created such an entry in the rejectlog:

2018-02-19 17:03:21 H=from.host [REDACTED] F=<REDACTED> rejected RCPT <[email protected]>: Unrouteable address

exim -bt [email protected] returns

R: system_aliases for [email protected]
[email protected] is undeliverable: Unrouteable address

I am trying to deploy a web application (RODA 2.0) as WAR on a debian stretch into tomcat 8.5 and openjdk 8, and I get a java.net.BindException: Address already in use when starting up (see full stacktrace at https://pastebin.com/SSDJX6yc). Now, the webapp really tries to listen on port 2552, but it is not used, and running lsof -ni :2552 in a loop shows that at no point is it actually used. On osx it succeeds starting even in tomcat, and successfully listens on the given port.

I realized that maybe tomcat security policies prevent this, but trying to use the catalina.policy from the osx machine yielded the same result. I also tried to add a grant entry to the original debian policy files:

grant codeBase "war:file:${catalina.base}/webapps/ROOT.war*" {
    permission java.net.SocketPermission "192.168.*:2552", "listen, connect, accept, resolve";
};

Do you have any idea what the actual problem could be, and how to solve it (aside from trying to modify RODA to not try to connect on the given port)?

I have an LXC container that has 4GB of swap, most of which is free:

# swapon -s
Filename                                Type            Size    Used    Priority
none                                    virtual         4096000 97004   0

However, Zabbix (2.2.5, zabbix-agentd 2.2.7) reports total swap space (and hence free swap space) as zero, and thus reports a problem.

How can I configure Zabbix to recognize the available swap space? Alternatively: is there a newer version of zabbix-agent that does have this problem?

When simply using the command line, the main strategy would be to use the cache git credential helper:

git config --global credential.helper cache
git config --global credential.username {{ gituser }}
git pull {{ repository1 }}
... asks password
... pulls
git pull {{ repository2 }}
... pulls
... etc.

But if I use the ansible git module, prompting does not work (nor is it practical). The only solution I currently see is to use:

- git: repo=https://{{ gituser }}:{{ gitpass }}@{{ repo_url }} dest={{ dest }}

Where I get gituser and gitpass using vars_prompt:, or from ansible's local secure storage. However, this has the unfornutate side effect that it stores the password in {{ dest }}/.git/config in plain text, which I would like to avoid.

Is there a way to set the password from ansible for the time of the playbook run, but not to store it on the server?

I am trying to insert a conditional block inside a conditional block:

- block:
  - postgresql_db: name={{ dbname }} state=absent
  - postgresql_db: name={{ dbname }}
  ...
  - block:
     - get_url: url={{ remote_database_dump }} dest={{ local_database_dump }}
     - command: pg_restore -d {{ dbname }} {{ local_database_dump }}
    when remote_database_dump != ""
  become: true
  become_user: postgres
  become_method: su
  when: db_recreate == "true"

But I get a ERROR! Syntax Error while loading YAML. message. If I remove the when remote_database_dump != "", it works fine.

Is this nesting possible? If yes, how?

I am running a private cloud (opennebula, KVM) where I am running VMs both directly using LVM Logical Volumes and using disk images on a file system (one is faster, the other is easier to migrate), all on top of raid5.

I managed to procure some SSDs that I can put into my servers, and I would like to use them as cache, most probably using DM-cache (as bcache needs a disk reformat and flashcache is still not mainline).

Now, as I would like to cache multiple LVs, I could create separate metadata and cache partitions for each one, or I could create a new LV, put dm-cache on top of that and then use it as a PV and move the previous LVs there one by one.

So the resulting layering would be:

1. md1 == sda+sdb+sdc+sdd
2. PV0 == md1
3. LV0 <- PV0 (I intend to leave the host OS's volumes uncached)
4. PV1 == LV0 + dmcache
5. (LV1, LV2, LV3, ...) <- PV1

So my question are:

• Does this make sense? :)
• Is there a significant (>5%) performance penalty for an additional LVM layer?
• Is there an inherent incompatibility issue in this setup that I should be aware of?