Category Archives: Netzwerk

Generate Cert with alternative Names

title: “Generate Cert with alternative Names”
date: 2020-11-25T16:08:29
slug: 1340-2

server_rootCA.csr.cnf

[req]
default\_bits = 2048
prompt = no
default\_md = sha256
distinguished\_name = dn
[dn]
C=DE
ST=Bayern
L=Muenchen
O=Strasse
OU=RootCA
emailAddress=thomas.asanger@noris.de
CN = elasticsearch-master-headless

v3.ext

authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt\_names
[alt\_names]
DNS.1 = elasticsearch
DNS.2 = elasticsearch.openshift-logging.svc
DNS.3 = elasticsearch.openshift-logging.svc.cluster.local
DNS.4 = elasticsearch-master.openshift-logging.svc
DNS.5 = elasticsearch-master.openshift-logging.svc.cluster.local
IP.1 = 127.0.0.1

openssl req -new -sha256 -nodes -out elastic.csr -newkey rsa:2048 -keyout elastic.key -config <( cat server\_rootCA.csr.cnf )
openssl x509 -req -in elastic.csr -CA tls.crt -CAkey tls.key -CAcreateserial -out elastic.crt -days 3650 -sha256 -extfile v3.ext
openssl x509 -in elastic.crt -text -noout

wireshark & openssl

title: “wireshark & openssl”
date: 2020-08-11T09:34:16
slug: wireshark

Show SNI:
ssl.handshake.extension.type == 0

Set TLS Version and Cipher
openssl s_client -connect master.hub-portal.fcp.mi.ci.cstx.cloud:443 -CAfile master-hub-portal-fcp-mi-ci-cstx-cloud-chain.pem -tls1_2 -cipher ECDHE-RSA-AES128-GCM-SHA256

NFS mount

title: “NFS mount”
date: 2019-01-29T09:37:12
slug: nfs-mount

1) Soft Mount

Suppose you have mounted a NFS filesystem using “soft mount”. When a program or application requests a file from the NFS filesystem, NFS client daemons will try to retrieve the data from the NFS server. But, if it doesn’t get any response from the NFS server (due to any crash or failure of NFS server), the NFS client will report an error to the process on the client machine requesting the file access. The advantage of this mechanism is “fast responsiveness” as it doesn’t wait for the NFS server to respond. But the main disadvantage of this method is data corruption or loss of data. So this is not a recommended option to use.

mount -o rw,soft host.nf\_server.com/home /techhome

2) Hard Mount

If you have mounted the NFS filesystem using hard mount, it will repeatedly retry to contact the server. Once the server is back online, the program will continue to execute undisturbed from the state where it was during server crash. We can use the mount option “intr” which allows NFS requests to be interrupted if the server goes down or cannot be reached. Hence the recommended settings are hard and intr options.

mount -o rw,hard,intr host.nf\_server.com/home /techhome

NFS uid/gid mapping

title: “NFS uid/gid mapping”
date: 2018-10-02T09:27:17
slug: nfs-uidgid-mapping

UPDATE: The following post is referring to the user-mode NFS server that some linux distributions had when I wrote the post back in 2007. Now (2013), most distro’s just use the kernel based NFS server, which does not include the uid/gid remapping as far as I am aware.

My debian etch box is a file server amongst other things and generally I
use NFS to mount its directories on other linux boxes, and as per an
earlier post I also mount these directories on the MacMini.

Generally access is read only, but I noticed my write access didn’t work
at all. I kept on getting permission denied errors. Of course, it was
because my uids and gids did not match up between client and server. Now the linux user mode NFS server (which is what I run) has a uid/gid remapping facility. I first
tried something like this in /etc/exports:

/somedir 10.1.2.0/255.255.255.0 (rw,insecure,map_static=/etc/nfs.map)

And set up my /etc/nfs.map file as :

remote local

gid 500 1000
uid 500 2003

So that means that if the client is uid 500, that it gets remapped to
uid 2003 on the server. And gid 500 on the client gets mapped to 1000 on
the server.

I tried it and it didn’t work.

Then I read that if you use subnet matching then some stuff doesn’t
work, so attempt two using the explicit IP of one of my clients:

/somedir 10.1.2.1(rw,insecure,map_static=/etc/nfs.map)

Stopped and started the NFS server and mounted on the client (linux at
this stage) and it all worked.

Then I added some entries into the map for the MacMini.And had my
/etc/exports as:

/somedir 10.1.2.1 (rw,insecure,map_static=/etc/nfs.map)
10.1.2.2(rw,insecure,map_static=/etc/nfs.map)

and my new /etc/nfs.map looked like:

remote local

gid 500 1000 # linux client
uid 500 2003 # linux client
gid 501 1000 # Mac client
uid 501 2003 # Mac client

That didn’t work. Well it worked on one of the clients, but not the
other. I think the mapping clashed, so I ended up having separate maps
for each client:

/somedir 10.1.2.1 (rw,insecure,map_static=/etc/nfs.map.linux)
10.1.2.2(rw,insecure,map_static=/etc/nfs.map.mac)

And split that nfs.map file appropriately.

Now it all worked.

eth0

title: “eth0”
date: 2018-09-05T14:55:51
slug: eth0

sed -i -e 's/GRUB\_CMDLINE\_LINUX=.\*/GRUB\_CMDLINE\_LINUX="net.ifnames=0 biosdevname=0"/' /etc/default/grub
grub-mkconfig -o /boot/grub/grub.cfg
sed -i -e 's/enp0s3/eth0/' /etc/network/interfaces