Linux Administration

Collection of helm-stuff

Nice things you can do with lsof # Show all active internet connections lsof -i # Show all active TCP connections lsof -iTCP lsof -iTCP:57123 # Show active TCP connection on port 57123 # Show all active IPv4 connections lsof -i4 lsof -i4:57123 # Show active IPv4 connection on port 57123 # Show all file descriptors for a user lsof -u $USER

Hugo is a framework for building static webpages. It pairs well with creating a git repository and creating a push-webhook which rebuilds the homepage every time you change it. This post is just documenting how to do just that for an existing hugo repository. Create a static repo with nginx pointing to it Clone a hugo repo and put it in /srv/hugo.iix.se Pop over to the folder and run hugo to generate a static page chown -R nginx:nginx /srv/hugo.iix.se Create a nginx vhost with location / { root /srv/hugo.iix.se/public } systemctl nginx reload Check that the page works Create an endpoint for updating This can be be done in a number of ways, but an easy way is creating a fastcgi endpoint in nginx, since we got that running already. ...

Various stuff I forget how I do it. View iptables # View iptables sudo iptables -nvL Add/Remove/Replace # Add a rule iptables -A INPUT -p tcp --dport 80 -j ACCEPT # Append to end of chain iptables -I INPUT 1 -p tcp --dport 80 -j ACCEPT # Insert at position 1 in chain # Delete a rule iptables -D INPUT 5 # 5 is index 5 in the INPUT-chain # Replace a rule iptables -R INPUT 1 -p tcp -s 192.168.0.0/24 --dport 80 -j ACCEPT # Replace rule at index 1 Persisting Generally, tables are saved in ...

Kubernetes + GCloud + Kind Cheatsheet Links Official Kubernetes Cheatsheet Kubectl Bash autocomplete source <(kubectl completion bash) Context - easy way of changing namespaces Contexts are saved to $HOME/.kube/config, so you can edit that file manually if you mess up. # One-time-only - create context kubectl config set-context iix --namespace=iix --user=kubernetes-admin --cluster=kubernetes # Later - use context kubectl config use-context iix Listing # List all images in the active namespace kubectl -n dev get pods -o jsonpath="{.items[*].spec.containers[*].image}" |tr -s '[[:space:]]' '\n' Modify existing daemonset kubectl get ds fluentd-gcp-v2.0 --namespace kube-system -o yaml > fluentd-gcp-ds.yaml # Replace stuff in fluentd-gcp-ds.yaml kubectl replace -f fluentd-gcp-ds.yaml Modify existing configmap Updating ConfigMap in the apiserver is more complicated than updating DaemonSet. It’s better to consider ConfigMap to be immutable. Then, in order to update the configuration, you should create ConfigMap with a new name and then change DaemonSet to point to it. ...

This page is compiled from my experiences of researching the bare minimum to make stuff work. Since SELinux is made to be secure, this approach might create security vulnerabilities if you don’t know what you are doing. Resources Introduction to SELinux (GitHub blog) Locate the problem In this example. My nginx installation is unable to access a file called test.txt. This is the journal log: Sep 22 20:01:32 hermes.iix.se audit[23928]: AVC avc: denied { read } for pid=23928 comm="nginx" name="test.txt" dev="vda1" ino=271350 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:var_t:s0 tclass=file permissive=0 The first thing we do is to asking audit whats up. this is usually done by piping the audit log to audit2why. If you don’t have audit, the logs should be in the /var/log/messages instead. ...

This is a very broad title, and will probably not help anyone except for me if this happens for me again. One day when I had to restart my KVM host, none of my guests had internet connection. The eth0 on the KVM host was attached to a bridge (br0) and that host had connectivity through the bridge. Here are some configs (which had not changed since it worked): # /etc/network/interfaces source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback # The primary network interface allow-hotplug eth0 iface eth0 inet manual #iface eth0 inet dhcp auto br0 iface br0 inet dhcp bridge_ports eth0 bridge_stp off bridge_fd 0 bridge_maxwait 0 Configuration seems good to me. I have never needed stp=on, so it should be alright. ...

sudo systemctl stop nginx sudo docker run --rm -it -p80:80 -p443:443 -v "/etc/letsencrypt:/etc/letsencrypt" -v "/var/lib/letsencrypt:/var/lib/letsencrypt" certbot/certbot certonly --expand --standalone -d yolo.iix.se sudo systemctl start nginx

How To Set Up a Postfix E-Mail Server with Dovecot How To use an SPF Record to Prevent Spoofing & Improve E-mail Reliability How To Install and Configure DKIM with Postfix on Debian Wheezy (Note: to get a PTR record back to your FQDN on Digital Ocean you must name the droplet to the FQDN)

I have docker container which wants access to a drive on its host, which in turn is mounted with cifs from a server on the local network. If you mount it normally with a -v host:container and try to access it from the container, you get an access denied. If you try the old classic SE-Linux-friendly -v host:container:Z, it will look like this from the container: root@c3ada26b1d90:/# l /data/* /data/backup: ls: cannot access '/data/backup/config.json': Permission denied 27177a66e938a02ae784c0bc9ccd74751a32c00f4fcaee22ef1d78894c70553a-stdin| config.json init-stdin| 27177a66e938a02ae784c0bc9ccd74751a32c00f4fcaee22ef1d78894c70553a-stdout| init-stderr| init-stdout| To make it work, you have to change the SE-Linux-type from cifs_t to something more container-y. In your /etc/fstab, you can mount it like this: ...

sudo -u postgres createuser USER sudo -u postgres createdb DB sudo -u postgres psql alter user USER with encrypted password 'PASS'; alter database DB owner to USER;

When I get some spare time I would like to make rsyslogd write its contents to database, and parse it through a web interface. In the meantime I’ll just collect some guides here. Writing syslog messages to MySQL, PostgreSQL or any other supported Database Handling a massive syslog database insert rate with Rsyslog Elasticsearch Elasticsearch - Logstash Elasticsearch - Kibana

Extending the certificate to also cover www.iix.se sudo certbot certonly --standalone -d iix.se,www.iix.se,monit.iix.se,test.iix.se Sat Nov 04 11:14 W44 Saving debug log to /var/log/letsencrypt/letsencrypt.log Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org ------------------------------------------------------------------------------- You have an existing certificate that contains a portion of the domains you requested (ref: /etc/letsencrypt/renewal/iix.se.conf) It contains these names: iix.se, monit.iix.se, test.iix.se You requested these names for the new certificate: iix.se, www.iix.se, monit.iix.se, test.iix.se. Do you want to expand and replace this existing certificate with the new certificate? ------------------------------------------------------------------------------- (E)xpand/(C)ancel: e Renewing an existing certificate Performing the following challenges: tls-sni-01 challenge for iix.se tls-sni-01 challenge for www.iix.se tls-sni-01 challenge for monit.iix.se tls-sni-01 challenge for test.iix.se /usr/lib/python2.7/dist-packages/OpenSSL/rand.py:58: UserWarning: implicit cast from 'char *' to a different pointer type: will be forbidden in the future (check that the types are as you expect; use an explicit ffi.cast() if they are correct) result_code = _lib.RAND_bytes(result_buffer, num_bytes) Waiting for verification... Cleaning up challenges Generating key (2048 bits): /etc/letsencrypt/keys/0009_key-certbot.pem Creating CSR: /etc/letsencrypt/csr/0009_csr-certbot.pem IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at /etc/letsencrypt/live/iix.se/fullchain.pem. Your cert will expire on 2018-02-02. To obtain a new or tweaked version of this certificate in the future, simply run certbot again. To non-interactively renew *all* of your certificates, run "certbot renew" - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le

# Restart single instance and refresh image sudo docker-compose up -d --build backend

This is an example of doing a quick and dirty restore of a database. Typically happens after doing something stupid, like running UPDATE without a WHERE (oops). In this case, we restore database iix-notes (which by pure coincidence is the same name as this site) from a daily backup. The database is hosted on a postgresql docker container, but it should work the same regardless. Fetch a backup and copy it to the docker container cd $HOME gpg -o iix-notes.daily.psql.gz -d /media/backup/hot/iix-notes.daily.psql.gz.gpg gunzip iix-notes.daily.psql.gz sudo docker cp iix-notes.daily.psql iixnotescompose_database_1:/tmp rm iix-notes.daily.psql Logon to the container, drop the old database, and load it from the backup sudo docker exec -it iixnotescompose_database_1 bash dropdb -U postgres iix-notes psql -U postgres -f /tmp/iix-notes.sql