In this post/howto, I’ll explain how to install Ansible as control and managed node on FreeBSD 12, CentOS 8 and Ubuntu 18. Then, I’ll explain how to create SSH keys so the nodes can communicate and some basic tasks. Then, I’ll show you how to create a playbook to install the latest updates and also install an Apache server with the default settings. Finally, I’ll show an example of how to use variables.

Control and managed nodes

A control node is where you execute all of your Ansible commands and eventually keep your playbooks, configs, inventory etc. It’s pretty much your workstation. A managed node is where the actual playbooks are executed. These are the main concepts and the terminology.
In my case, I have 4 VMs/instances. The main one which is the control node and 3 managed nodes.

CentOS 8

If you want to install Ansible on the control node, you have to install Python 3.x first.

sudo dnf install python3

This will also install pip. Type python3 to test, CTRL-D to exit and then install ansible.

sudo pip3 install ansible

Type ansible to test.

Ubuntu

Ubuntu comes with python installed, but not with pip. Install pip with:

sudo apt install python3-pip

Then install ansible with:

sudo pip3 install ansible

Type ansible to test.

FreeBSD

FreeBSD comes with python installed but pip is not. Check the version and then install the same pip version.

ls -l /usr/local/bin/python*

If your output is for example python37, install the same pip version.

pkg install py37-pip

Then install ansible.

pip install ansible

Type ansible to test.

SSH keys

While Ansible can use standard *nix username/password authentication, it’s recommended that you use SSH keys to communicate from control node to the managed nodes. For that, you’ll have to create your SSH keys. Let’s say you have an account on your control node and the username is admin. You also want to use the user ansible on the managed nodes. It really doesn’t matter what usernames you are going to choose. You can always override the keys to use, but in this case, I’ll create a key on the control node and send it to all managed nodes.
On the control node, regardless of your OS, do:

ssh-keygen -b 4096

This will create a subfolder .ssh with two files: id_rsa and id_rsa.pub. The former is your private key and the later is your public key.
Copy the key to your managed nodes.

ssh-copy-id ansible@nodeX.andreev.local

This will copy my key for the user admin to the node X under the ansible user. Then test the passwordless connection.

ssh ansible@nodeX.andreev.local

Mind that the use of FQDN (nodex.andreev.local) vs. hostname (nodex) is important. For SSH these two are different. Once you log to the managed node, the node will be added to the list of known hosts in the file .ssh/known_hosts.

Inventory and the config file

Ansible uses the inventory files to execute an action against using the options and parameters specified in the config file. The config file is /etc/ansible/ansible.cfg for CentOS and Ubuntu and /usr/local/etc/ansible/ansible.cfg for FreeBSD. You can also put the inventory file in the same directory and name it as you wish, but you have to specify the inventory as a parameter on the command line or an entry in the config file. In addition, you can have your config file in your current directory or under the .ansible directory in your home folder. ansible.cfg in the current directory has a precedence over .ansible.cfg in the home directory which has a precedence over /etc/ansible/ansible.cfg. Here is how that looks.
Let’s list all the inventory.

ansible --list-hosts all

You’ll get a message that there is no inventory file. Let’s create one, we’ll name it inventory.txt.

[freebsd]
node1.andreev.local
[centos]
node2.andreev.local
[ubuntu]
node3.andreev.local
[bsd]
node1.andreev.local
[linux]
node2.andreev.local
node3.andreev.local

If we specify the inventory file, we’ll get this.

ansible --list-hosts all -i inventory.txt
  hosts (3):
    node1.andreev.local
    node2.andreev.local
    node3.andreev.local

If we create a config file, we can tell ansible where to look for the inventory. Create a file ansible.cfg in the same directory.

[defaults]
inventory=/home/<somewhere>/inventory.txt

If you do ansible –list-hosts all now, you’ll get the same result as before, but without specifying the inventory file.
Or something like this.

ansible all -m shell -a "uname -a"
node1.andreev.local | CHANGED | rc=0 >>
FreeBSD node1.andreev.local 12.1-RELEASE FreeBSD 12.1-RELEASE r354233 GENERIC  amd64
node2.andreev.local | CHANGED | rc=0 >>
Linux node2.andreev.local 4.18.0-193.14.2.el8_2.x86_64 #1 SMP Sun Jul 26 03:54:29 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
node3.andreev.local | CHANGED | rc=0 >>
Linux node3.andreev.local 4.15.0-129-generic #132-Ubuntu SMP Thu Dec 10 14:02:26 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

By default, ansible runs on the managed node with the currently logged user that executes the playbook on the control node. If you get an error saying that the previous command cannot connect to the host, you have to specify the same user that you used when you test the connection with ssh -user-@managednode. So, edit ansible.cfg and add this line.

remote_user=<user>

We can target only the group linux which consists of Linux hosts only in the inventory file.

ansible linux -m shell -a "date"
node3.andreev.local | CHANGED | rc=0 >>
Fri Jan  8 15:23:40 UTC 2021
node2.andreev.local | CHANGED | rc=0 >>
Fri Jan  8 10:23:40 EST 2021

Playbooks

The playbooks are the blueprints of the automation tasks. Instead of running the ansible command to execute each task separately, we combine these tasks in a YAML file and execute them sequentially. Here are 3 playbooks that update each of our managed nodes. There is no update module for FreeBSD, so we use the shell command.

# freebsd-update.yml
---
  - hosts: freebsd
    become: yes
    tasks:
      - name: Fetch all packages
        shell: freebsd-update fetch
      - name: Install FreeBSD updates
        shell: freebsd-update install
      - name: Reboot
        reboot:

For CentOS we’ll use yum.

# centos-update.yml
---
  - hosts: centos
    become: yes
    tasks:
      - name: Update all packages
        yum: name=* state=latest
      - name: Reboot
        reboot:

…and for Ubuntu we’ll use apt.

# ubuntu-update.yml
---
  - hosts: ubuntu
    become: yes
    tasks:
      - name: Update all packages
        apt: name=* state=latest
      - name: Reboot
        reboot:

Save these files with a YAML extension and you can execute them with the following command.

ansible-playbook <filename>

All of them will probably fail. That’s because your ansible user on the managed nodes is required a password when executing a sudo command. In order to fix that, you’ll have to add a line in the sudoers file. Edit this file using the visudo command.

visudo

…and then add this line right before the @includedir <...> which is the last line in the file.

ansible ALL=(ALL) NOPASSWD:ALL

Where ansible is the user that runs the playbooks on the managed nodes. FreeBSD doesn’t come with sudo preinstalled, so you’ll have to install it first on the managed node.

pkg install sudo

These playbooks will update the OS and the packages for the Linux. For FreeBSD, it will update only the OS. Here is another example of playbooks that will install Apache server in a default configuration and change the ServerName and ServerAdmin lines. We’ll also install PHP and test our server.
If you have a firewall enabled, make sure you open it up first on CentOS. Ubuntu and FreeBSD do not come with the firewall enabled.

firewall-cmd --zone=public --permanent --add-service=http
firewall-cmd --reload

For FreeBSD, the playbook looks like this.

# freebsd-apache.yml
---
  - hosts: freebsd
    become: yes
    tasks:
      - name: Install apache and php
        pkgng:
          name:
            - apache24
            - php74
            - mod_php74
          state:  present
      - name: Start on reboot
        service: name=apache24 enabled=yes
      - name: Copy index.php
        copy:
          src: ../files/index.php
          dest: /usr/local/www/apache24/data
          mode: 0755
      - name: Copy mod_php.conf
        copy:
          src: ../files/mod_php.conf
          dest: /usr/local/etc/apache24/modules.d
          mode: 0755
      - name: Start apache now
        service: name=apache24 state=started

For CentOS, it looks like this.

# centos-apache.yml
---
  - hosts: centos
    become: yes
    tasks:
      - name: Install apache and php
        yum:
          name:
            - httpd
            - php
          state:  present
      - name: Start apache now and on reboot
        service: name=httpd state=started enabled=yes
      - name: Copy index.php
        copy:
          src: ../files/index.php
          dest: /var/www/html
          mode: 0755

…and for Ubuntu it looks like this.

# ubuntu-apache.yml
---
  - hosts: ubuntu
    become: yes
    tasks:
      - name: Install apache and php
        apt:
          name:
            - apache2
            - php
          state:  present
      - name: Start apache now and on reboot
        service: name=apache2 state=started enabled=yes
      - name: Copy index.php
        copy:
          src: ../files/index.php
          dest: /var/www/html
          mode: 0755

You will also need these two files in a directory called files. In my case it’s one level above the directory where I keep my playbooks.
index.php

<?php
  phpinfo();
?>

001_mod-php.conf

<IfModule dir_module>
    DirectoryIndex index.php index.html
    <FilesMatch "\.php$">
        SetHandler application/x-httpd-php
    </FilesMatch>
    <FilesMatch "\.phps$">
        SetHandler application/x-httpd-php-source
    </FilesMatch>
</IfModule>

The index.php file is the standard test file to test the PHP distributions and the 001_mod-php.conf is needed for FreeBSD only. As you can see the playbooks differ quite a bit for these three OSes. Once you deploy the playbooks, you can test the result by going to http://[nodeX]/index.php.
Looks like this.

Service handlers

Service handlers are used only when a change is made on the managed node. For example, we can restart a service only if the config file was changed. If the file is not changed, then there is no need to restart. Here is an example of a service handler. We’ll restart postfix service only if the main.cf file was changed.

# service-handler.yml
---
- hosts: centos
  become: yes
  tasks:
  - name: Configure main.cf
    lineinfile:
      path: /etc/postfix/main.cf
      regexp: ^#mydomain
      line: 'mydomain = example.com'
    notify: restart postfix

  handlers:
  - name: restart postfix
    service: name=postfix state=restarted

Make sure that the name for the handler is the same (lines 11 and 14), so Ansible knows what service handlers is referred.

Variables

When ansible runs a playbook on a managed node, the first task is to gather info about the managed node. The info is a bunch of settings that we can use in our playbooks. For example, if you execute the following command, you can see the IP address, the CPU model, python version etc.

ansible -m setup <node>

We can use these settings and use them as variables if we need them. For example, this playbook displays the hostname and the IP.

# showip.yml
---
  - hosts: freebsd
    become: yes
    tasks:
      - name: Show the IP address
        debug:
          msg: "The hostname is {{ inventory_hostname}}  and the IP is {{ansible_default_ipv4.address }}"

And if you run the playbook, you’ll see something like this.

TASK [Show the IP address] *********************************************************************************************
ok: [node1.andreev.local] => {
    "msg": "The hostname is node1.andreev.local  and the IP is 192.168.1.211"
}

Here is another example of using variables. In this case, we’ll specify a file and change the ownership and the mode.

# owner.yml
---
  - hosts: centos
    become: yes
    vars:
      filename: "/var/www/html/index.php"
    tasks:
      - name: Change the owner of the file
        file:
          path: "{{ filename }}"
          owner: apache
          group: apache
          mode: '0755'

In case we want to assign an output to a variable, we’ll have to use the keyword register. Here is an example of how to get the output from a command and print it on the screen with the keyword debug.

# variables.yml
---
  - hosts: freebsd

    tasks:
    - name: Get the uptime manually
      command: uptime
      register: var_uptime

    - name: Print the uptime
      debug:
        msg: The uptime is "{{ var_uptime }}"

Roles

Roles let you automatically load related vars_files, tasks, handlers, and other Ansible artifacts based on a known file structure. Once you group your content in roles, you can easily reuse them and share them with other users. The idea is to separate the tasks, handlers and vars in different files. Let’s see this playbook for example. It changes a line in main.cf file, restarts postfix and copies a file under the postfix main directory.

# roles.yml
---
  - hosts: centos
    become: yes

    vars:
      filevd: "/etc/postfix/virtual_domains"
      cfgpostfix: "/etc/postfix/main.cf"


    tasks:
    - name: Configure main.cf
      lineinfile:
        path: "{{ cfgpostfix }}"
        regexp: ^#mydomain
        line: 'mydomain = example.com'
      notify: restart postfix
    - name: Copy virtual_domains
      copy:
        src: ../files/virtual_domains
        dest: "{{ filevd }}"
        mode: 0755

    handlers:
    - name: restart postfix
      service: name=postfix state=restarted

We can rewrite this file by separating the tasks, variables, files and handlers. Run this command.

ansible-galaxy role init postfix

If you look at the file/directory structure of the newly created directory postfix, it looks like this.

tree postfix
postfix
├── defaults
│   └── main.yml
├── files
├── handlers
│   └── main.yml
├── meta
│   └── main.yml
├── README.md
├── tasks
│   └── main.yml
├── templates
├── tests
│   ├── inventory
│   └── test.yml
└── vars
    └── main.yml

Create a file virtual_domains under the files directory.

echo "mydomain.com" > postfix/files/virtual_domains

Move the config for vars, handlers and tasks in the separate main.yml files. For example, this is how my files look like.
postfix/vars/main.yml

---
# vars file for postfix

  filevd: "/etc/postfix/virtual_domains"
  cfgpostfix: "/etc/postfix/main.cf"

As you can see the keyword vars: does not exists. Ansible knows that this file is for vars so there is no need to enter the vars keyboard.
postfix/tasks/main.yml

---
# tasks file for postfix

  - name: Configure main.cf
    lineinfile:
      path: "{{ cfgpostfix }}"
      regexp: ^#mydomain
      line: 'mydomain = example.com'
    notify: restart postfix
  - name: Copy virtual_domains
    copy:
      src: ../files/virtual_domains
      dest: "{{ filevd }}"
      mode: 0755

postfix/handlers/main.yml

---
# handlers file for postfix

  - name: restart postfix
    service: name=postfix state=restarted

Finally, create a file called something.yml that will be your main file. This file has to be outside the postfix directory structure.
In my case it looks like this.
something.yml

# something.yml
---
  - hosts: centos
    become: yes
    roles:
      - postfix

Now, if you execute this playbook, ansible will automatically execute the rest of the dependant playbooks as well.

ansible-playbook something.yml

Error handling

Sometimes we want certain changes to be ignored. Sometimes, we know the behavior of certain commands and we know that they might return non-zero code and we want that ignored. For example, consider this part of a playbook.

- hosts: centos
  tasks: 
  - name: Type something that will fail
    command: thiscommanddoesntexist
    ignore_errors: yes

  - name: Run command remotely
    command: /usr/local/bin/somecommand
    register: cmd_result
    changed_when: cmd_result == 2

Ansible would report a task as changed as long as the command (or) script gives zero return code.
In the first part, we know that the task will fail, but we decide to ignore it using the keyword ignore_errors. No matter what the command returns, ignore_errors: yes will never report to ansible that the command failed.
In the second command we can ignore the error based on the output of the command. For example, if the output is 2, the the error will be ignored. If cmd_result is not equal to 2, the task will be marked as changed.
So whenever this condition is true, the task will be marked as changed.

Tags

Tags are used when you have a playbook with several tasks and you need to run only specific parts of it instead of running the entire playbook. You use tags to execute or skip selected tasks. Let’s say we have this playbook that installs Docker on Centos and has multiple tasks. As you can notice in lines 12, 24, 37 and 45 we have a new line with a keyword tags that we use to tag certain tasks. The purpose of this is to include or exclude these tasks from the playbook.

# centos-docker.yml
---
- name: Install docker
  hosts: centos
  become: true

  tasks:
    - name: Install yum utils
      yum:
        name: yum-utils
        state: latest
      tags: install

    - name: Install device-mapper-persistent-data
      yum:
        name: device-mapper-persistent-data
        state: latest
      tags: install

    - name: Install lvm2
      yum:
        name: lvm2
        state: latest
      tags: install

    - name: Add Docker repo
      get_url:
        url: https://download.docker.com/linux/centos/docker-ce.repo
        dest: /etc/yum.repos.d/docer-ce.repo
      become: yes

    - name: Install Docker
      package:
        name: docker-ce
        state: latest
      become: yes
      tags: install

    - name: Start Docker service
      service:
        name: docker
        state: started
        enabled: yes
      become: yes
      tags: start

Now, with the command below, we can execute the playbook and only the tasks tagged with install will be executed.

ansible-playbook centos-docker.yaml --tags install

We can also tell ansible to NOT run those tasks tagged with install.

ansible-playbook centos-docker.yaml --skip-tags install

You can add multiple tags per task, e.g.

tags:
  - cleanup_app
  - cleanup_web

Ansible reserves two tag names for special behavior: always and never. If you assign the always tag to a task or play, Ansible will always run that task or play, unless you specifically skip it (–skip-tags always). If you assign the never tag to a task or play, Ansible will skip that task or play unless you specifically request it (–tags never).

Ansible Vault

Ansible Vault encrypts variables and files so you can protect sensitive content such as passwords or keys rather than leaving it visible as plaintext in playbooks or roles.
First, you have to create a vaulted file where we’ll store the passwords. When you run this command it will ask you to create a password and then an empty file will show up.

ansible-vault create secrets.yml

Add some passwords there and save the file.

mysql_pwd: "DifficultPassword"
ht_pwd: "PasswordXYZ"

If you look at the file now, you’ll see that it’s encrypted and you can’t see the passwords anymore.
If you want to edit the file do ansible-vault edit secrets.yaml and enter the vault password.
Create a small playbook that displays the password.

# centos-vault.yml
---
- hosts: centos
  vars_files:
    - secrets.yml

  tasks:
  - name: Show mysql pwd
    debug:
      msg: "{{ mysql_pwd }}"

If you run the playbook now, ansible will throw an error saying ERROR! Attempting to decrypt but no vault secrets found. You have to specify the parameter –ask-vault-pass and enter the vault password when prompted.

Prompts

In case you need to pause the playbook execution and ask the user for some input such as confirmation or password, use prompts.
If you want the output to echo, use private: no, otherwise what you type won’t show up on the screen. Here is an example of a playbook that asks you to confirm if a file needs to be copied to the node. If you type yes and hit enter, the file will be copied, otherwise it won’t.

# centos-prompt.yml
---
- hosts: centos
  become: yes

  vars_prompt:
    name: upload
    private: no
    prompt: "Do you want to upload xyz.txt?"

  tasks:
  - name: Upload xyz.txt
    copy:
      src: xyz.txt
      dest: /var/log
    when: upload == "yes"

Useful options

ansible-playbook <name> --syntax-check # checks the syntax of the playbook
ansible-playbook <name> --check # does a dry run, reports the will-be changes, but the playbook is not executed
ansible-playbook <name> --step # ask to confirm each-step

I have a bunch of test CentOS/FreeBSD servers and I wanted to get all the notifications sent to my e-mail instead of logging to each server and check the status of each one of them. Some of my servers are behind my home network where outbound port 25 (SMTP) is blocked by the ISP. So, I decided to use my main postfix server which is already configured to use port 587 for SMTP using TLS. In this post, I’ll explain how I configured my test servers to relay e-mails.
Use the following links to see how I configured the postfix main server for CentOS and FreeBSD.

CentOS 7

There are some prerequisites for CentOS 7. It comes with postfix installed and it has built-in Cyrus SASL already, but we need another Cyrus SASL package for login support. In addition, CentOS doesn’t come up with the mail command, so we have to install that as well.

Prerequisites

Install Cyrus SASL package and the mail client.

yum install cyrus-sasl-plain mailx

postfix main config file

Edit /etc/postfix/main.cf and add these lines at the end.

relayhost = [server.domain.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_security_options = noanonymous
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_use_tls = yes
smtp_tls_CAfile = /etc/ssl/certs/server.domain.com.crt

The first line is your main postfix server that will receive the e-mail from the client servers, the 4th line is the file where you are going to store the username and password for the user that’s able to login to the main postfix server and the 6th line is the certificate of the main postfix server.

SASL Authentication

Edit /etc/postfix/sasl_passwd and add this line.

[server.domain.com]:587 mail@domain.com:YourPassword

You have to specify your main postfix server, the username and the password for a valid user that’s able to login to that server and receive e-mails. Once completed, execute postmap.

postmap /etc/postfix/sasl_passwd

e-mails to relay

I wanted to send all of my root e-mails to my main server, so what you have to do is edit /etc/aliases and scroll all the way down at the bottom. Un-comment the root line and specify where do you want your root emails to be forwarded.

root: mail@domain.com

If you have some cron jobs that run under some other username, specify them in this file, e.g. someuser: some-email@email.com.
After you are done, type newaliases.

newaliases

Public certificate

You will also need the public certificate of your e-mail server. Get the certificate in a PEM format and paste it into a new file /etc/ssl/certs/server.domain.com.crt. Or, in my case, I have a wildcard certificate for my domain, so I can get it using this command.

openssl s_client -connect server.domain.com:443 < /dev/null | \
sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > /etc/ssl/certs/server.domain.com.crt

Final step

Restart the postfix server on the client server, send a test e-mail and check the result.

systemctl restart postfix
echo "This is a test." | mail -s "Test e-mail" root
tail /var/log/maillog

FreeBSD 11

Unlike CentOS, FreeBSD doesn’t come up with postfix, instead it uses sendmail. So, we have to remove sendmail, install postfix and follow similar config as with CentOS.

Prerequisites

We have to install postfix from the ports because it doesn’t come up with Cyrus SASL. It comes with dovecot SASL, but I am not sure if it works in a client config. On the other hand, FreeBSD comes with mail installed. Install the postfix port, not the package.

cd /usr/ports

If you get an error that there is no such file or directory, get the ports tree. If you can cd to that folder, skip the step below to install the ports tree.

portsnap fetch
portsnap extract

Install postfix.

cd /usr/ports/mail/postfix
make all install clear

When this dialog box pops-up, select BDB and SASL as highlighted.

Execute these lines so you replace sendmail with postfix.

sysrc postfix_enable="YES"
sysrc sendmail_enable="NONE"
mv /usr/local/etc/mail/mailer.conf /usr/local/etc/mail/mailer.conf.old
install -m 0644 /usr/local/share/postfix/mailer.conf.postfix /usr/local/etc/mail/mailer.conf

Add the following lines to /etc/defaults/periodic.conf

daily_clean_hoststat_enable="NO"
daily_status_mail_rejects_enable="NO"
daily_status_include_submit_mailq="NO"
daily_submit_queuerun="NO"

Make sure Cyrus SASL is installed.

postconf -a

You should see cyrus and dovecot there.

postfix main config file

Edit /usr/local/etc/postfix/main.cf and add these lines at the end.

relayhost = [server.domain.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_security_options = noanonymous
smtp_sasl_password_maps = hash:/usr/local/etc/postfix/sasl_passwd
smtp_use_tls = yes
smtp_tls_CAfile = /usr/local/etc/ssl/server.domain.com.crt

The first line is your main postfix server that will receive the e-mail from the client servers, the 4th line is the file where you are going to store the username and password for the user that’s able to login to the main postfix server and the 6th line is the certificate of the main postfix server.

SASL Authentication

Edit /usr/local/etc/postfix/sasl_passwd and add this line.

[server.domain.com]:587 mail@domain.com:YourPassword

You have to specify your main postfix server, the username and the password for a valid user that’s able to login to that server and receive e-mails. Once completed, execute postmap.

postmap /usr/local/etc/postfix/sasl_passwd

e-mails to relay

I wanted to send all of my root e-mails to my main server, so what you have to do is edit /etc/aliases and scroll a little bit way down. Un-comment the root line and specify where do you want your root emails to be forwarded.

root: mail@domain.com

If you have some cron jobs that run under some other username, specify them in this file, e.g. someuser: some-email@email.com.
After you are done, type newaliases.

newaliases

Public certificate

You will also need the public certificate of your e-mail server. Get the certificate in a PEM format and paste it into a new file /usr/local/etc/ssl/server.domain.com.crt. Or, in my case, I have a wildcard certificate for my domain, so I can get it using this command.

openssl s_client -connect server.domain.com:443 < /dev/null | \
sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > /usr/local/etc/ssl/server.domain.com.crt

Final step

Restart the postfix server on the client server, send a test e-mail and check the result.

service postfix restart
echo "This is a test." | mail -s "Test e-mail" root
tail /var/log/maillog

You will notice that the e-mails that come from FreeBSD are always sent by Charlie Root. If you have multiple FreeBSD boxes, the e-mails from various FreeBSD servers will come as Charlie Root which might be a bit confusing. So do a chpass and change the line Full Name, so instead of Full Name: Charlie &, do something like Full Name: servername Charlie &.

chpass

Do :wq if your default editor is vi to save the changes.

norem for Linux/*BSD

A small utility written in Bourne shell (compatible with both sh and bash, which means works without changes on all *BSD/Linux) that strips comments from a source file. E.g. I am too lazy to scroll through /etc/ssh/sshd_config file to look for any valid directives.
Here is /etc/ssh/sshd_config on FreeBSD.

#       $OpenBSD: sshd_config,v 1.98 2016/02/17 05:29:04 djm Exp $
#       $FreeBSD: releng/10.3/crypto/openssh/sshd_config 296853 2016-03-14 13:05:13Z des $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

# Note that some of FreeBSD's defaults differ from OpenBSD's, and
# FreeBSD has a few additional options.

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# The default requires explicit activation of protocol 1
#Protocol 2

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024

# Ciphers and keying
#RekeyLimit default none

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin no
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#RSAAuthentication yes
#PubkeyAuthentication yes

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
#AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# Change to yes to enable built-in password authentication.
#PasswordAuthentication no
#PermitEmptyPasswords no

# Change to no to disable PAM authentication
#ChallengeResponseAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'no' to disable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
#UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation sandbox
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum FreeBSD-20160310

# no default banner path
#Banner none

# override default of no subsystems
Subsystem       sftp    /usr/libexec/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#       X11Forwarding no
#       AllowTcpForwarding no
#       PermitTTY no
#       ForceCommand cvs server

With this utility, I can just do:

norem -f /etc/ssh/sshd_config

… and voila…You have the meat without the bones.

Subsystem       sftp    /usr/libexec/sftp-server

Almost all *nix utilities have “#” as a comment, but some languages such as Java and C++ use “//” for comments. In this case, we have to run:

norem -f file -c "/"

The utility is not smart enough for multi-line comments such as “/*…*/”
Here is the source:

#!/bin/sh

usage()
{
    echo "usage: norem [-f file ] | [-c char] | [-e]] | [-h]]"
    echo "Prints a file skipping the lines that start with -c"
    echo "By default empty lines are not printed, use -e yes to include them"
    echo "Kliment Andreev - 2016"
}

if [ "$#" == "0" ]; then
        usage
        exit 1
fi

while [ $# -gt 0 ]; do
        key="$1"

        case $key in
                -f|--file)
                        FILENAME="$2"
                    shift
                        ;;
        -c|--char)
                        CHARACTER="$2"
                        shift
                ;;
                -e|--empty)
                EMPTY="$2"
                shift
                ;;
        *)
                usage
                        exit
                ;;
        esac
        shift
done

if [ -z "${CHARACTER}" ]; then
        CHARACTER="#"
fi

if [ -z "${EMPTY}" ]; then
        cat ${FILENAME} | sed "/^\\${CHARACTER}/d" | awk /./
else
        cat ${FILENAME} |sed "/^\\${CHARACTER}/d"
fi

norem for PowerShell

The same utility for PowerShell. The input parameters are the same.

Param(
	[string]$fileName,
	[string]$char="#",
	[string]$empty
)

function usage {
    Write-Host "usage: norem [-f file ] | [-c char] | [-e]]"
    Write-Host "Prints a file skipping the lines that start with -c"
    Write-Host "By default empty lines are not printed, use -e yes to include them"
    Write-Host "Kliment Andreev - 2016"
}

if ($psboundparameters.Count -eq 0) {
    usage
    exit
}

if ($empty.ToUpper().Contains("Y")) {
    Get-Content $fileName | Where { $_ -notmatch "^" + $char }
}
else {
    Get-Content $fileName | Where { $_ -notmatch "^" + $char } | Where {$_.trim() -ne ""}
}

I have two registered domains both pointing to my FreeBSD external IP. The first one is chombe.org and I receive these e-mails on my FreeBSD using postfix. The second domain is klimentandreev.com and I use Exchange 2003 to receive e-mails for this domain. Since Exchange is on the internal network, I have to configure postfix to relay all e-mails for klimentandreev.com to the Exchange box.

First, I made sure that I can ping klimentandreev.com from FreeBSD box and that it will resolve to my internal IP. Next, I edited main.cf and changed relay_domains to be like this.

relay_domains = $mydestionation, /usr/local/etc/postfix/relay-domains 

Then, I created that file and added the following lines.

# Relay domains
klimentandreev.com
other-domain-that-i-will-probably-buy.com

After that, I reloaded postfix with /usr/local/etc/rc.d/postfix reload and I verified that postfix is relaying OK. I didn’t have to configure anything on the Exchange box.

This is a method to install OpenVPN client on Ubuntu 9.04. First, download OpenVPN client from http://openvpn.net/release/openvpn-2.0.9.tar.gz. Unpack it, but do not install it yet. Then, download lzo-2.03 compression library from http://www.oberhumer.com/opensource/lzo/download/lzo-2.03.tar.gz.

Before installing it, do:

apt-get install libcurl4-openssl-dev 

Then unpack lzo-2.03, cd to that folder and do:

./configure
sudo make
sudo make check
sudo make test
sudo make install 

Once you are done with lzo install, cd to openvpn folder and do the following.

./configure
sudo make
sudo make install 

Now, put your config file under /etc/client.ovpn and your keys under your Documents folder. Make sure that you update client.ovpn so it reflects the new path. You can start the client using:

/usr/local/sbin/openvpn --config /etc/client.ovpn

Next, you can create a shortcut or “Launcher”. Make a small script /usr/local/bin/openvpn.sh and put the following lines.

#!/bin/bash
sudo /usr/local/sbin/openvpn --config /etc/client.ovpn

Change the permissions with chmod +x or chmod 744 if you want to have exclusive execute rights and then do:

sudo updatedb 

Right-click anywhere on the desktop, choose “Create Launcher”, choose “Application in Terminal” and browse for the .sh script that you just made.

Recently I got a laptop that came without CD or floppy. This laptop supports PXE boot so the only choice was to install Ubuntu over the network. In order to do that, I needed a DHCP server that supports PXE boot, tftp server and of course the boot file that will start the installation over the network. You can see my previous article on how to setup a DHCP server on OpenBSD. Installation of the tftp server is very easy on OpenBSD. You have to edit /etc/inetd.conf and uncomment the first entry for tftp.

ident           stream  tcp     nowait  _identd /usr/libexec/identd     identd -el
ident           stream  tcp6    nowait  _identd /usr/libexec/identd     identd -el
tftp            dgram   udp     wait    root    /usr/libexec/tftpd      tftpd -s /tftpboot
#tftp           dgram   udp6    wait    root    /usr/libexec/tftpd      tftpd -s /tftpboot

Now, you need to refresh inetd process and create the home/root folder for the tftp.

kill -HUP `cat /var/run/inetd.pid`
mkdir /tftpboot  

Make sure that tftp is working. Type q to exit.

tftp localhost
tftp> q

Next, you have to download the Ubuntu network installation file and place it in /tftpboot. Put this file in /tftpboot and unpack it with:

tar xzvf netboot.tar.gz

You have to change the MAC address in /etc/dhcpd.conf to match the MAC address on the computer where you want to install Ubuntu. Restart the computer, choose network boot and install.