C# .NET Core is a highly performant programming language created by Microsoft, which is an evolution of the legacy .NET Framework. Notably the latest version now natively supports operating systems other than Windows, such as Linux or MACOS making it much more widely adopted.

Within this guide we’ll go through the following steps, feel free to complete all if it’s a fresh setup, or just pick the bits that suit what you’re trying to achieve:

1. Create a Ubuntu Virtual Machine
2. Install the .NET Core Runtime
3. Setup Nginx as a Web Server
4. Optionally install MySQL Database
5. Create GitHub Actions for CI/CD

1 – Create Virtual Machine.

To begin we create a Virtual Machine on the Internet which will host our application – We are using Digital Ocean in this example, however any other provider with a similar specification should work just as well. When creating the droplet within Digital Ocean we’ve gone for the smallest Virtual Machine available:

• Distribution – Ubuntu 20.04 (LTS) x64
• Plan – Shared CPU, Basic – $5/pm (1GB RAM, 1 vCPU, 25GB Disk)
• Authentication – SSH Keys. You must use SSH keys and not password authentication to perform the later CI/CD integration with GitHub.

If you are following along then the same specification should be fine too, however websites with higher traffic may need to consider an increase of the CPU/RAM – This is fairly trivial to upgrade later on once you are setup, so don’t worry about starting with this amount.

Once the Droplet has finished building you should see it’s Public IP address which you should now be able to SSH to, remember that you’ll need to connect using the SSH Key provided when building the Virtual Machine.

When using PuTTY on Windows the key file is set within Connection > SSH > Auth and select it within the “Private key file for authentication” field. Also, once you connect the Password prompt is to decrypt the key file, it is not for the user of the remote machine.

To begin with we will ensure the image we have is the most up-to-date by running the update and upgrade commands.

apt update -y
apt upgrade -y

2 – Setup .NET Core Runtimes on Ubuntu and Setup Service

Now we need to let Ubuntu know about the Microsoft repository for Ubuntu, which once registered we should be able to download the latest .NET SDK’s from – To do that we issue these commands in our SSH window:

cd ~
wget -q https://packages.microsoft.com/config/ubuntu/20.04/packages-microsoft-prod.deb
sudo dpkg -i packages-microsoft-prod.deb
sudo add-apt-repository universe

Now the repository is setup we should be able to install some prerequisites, and then also the actual .NET 6.0 SDK

sudo apt install apt-transport-https -y
sudo apt update -y
sudo apt install dotnet-sdk-6.0 -y

So that’s actually all that needs to be done for getting .NET Core running on an Ubuntu server, next we’ll setup a Webserver so that we can accept HTTP requests from clients, and forward them onto our application.

Now we need to create a file that will define our service, so Ubuntu knows how to start/stop the service on our request, at boot and when we want to deploy the service – The “yourservicename” should be replaced with what ever makes sense for your application.

You will also see that we reference a folder in the “/var/www/” directory that is not yet created, this is where our application will live – Again change the “your_domain” to something that makes sense, but don’t worry that this folder doesn’t exist yet, we’ll create that when installing Nginx.

sudo nano /etc/systemd/system/yourservicename.service

[Unit]
Description=YourServiceNameWeb

[Service]
WorkingDirectory=/var/www/your_domain
ExecStart=/usr/bin/dotnet /var/www/your_domain/DemoApplication.dll
Restart=always
RestartSec=10
SyslogIdentifier=YourServiceNameWeb
User=www-data
Environment=ASPNETCORE_ENVIRONMENT=Production
Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false

[Install]
WantedBy=multi-user.target

Within the above you will want to edit the following elements to match your environment

• Description – Call this anything logical, typically I copy the name of the service
• WorkingDirectory – Should be the folder you created before, that will house your application
• SyslogIdentifier – I would match the service name again
• User – Should be the local Linux user that you want to run the application, I normally match that of Nginx which uses www-data, it should not be “root”

Finally we want to ensure that if the server ever reboots our service will automatically restart, that is done with the below command – Again replacing the “yourservicename” with what ever you called the above file, before the “.service”

sudo systemctl enable yourservicename

3 – Setup the NGINX Web Server for .NET Core

Here we will install NGINX which is our web server, but we will also install Certbox on the server, this will allow us to automagically request an SSL Certificate from LetsEncrypt (for Free), and it’ll then update our Web Server configuration to use the newly created certificate – Gone are the days where we need to pay for SSL certificates, and where the whole process of requesting and installing was a complete pain!

sudo apt install nginx certbot python3-certbot-nginx -y

You should find that NGINX is now actually already running on the server, if you run the following command you should see a running status in the output:

systemctl status nginx

nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2021-11-11 13:36:43 UTC; 4min 34s ago
       Docs: man:nginx(8)
   Main PID: 27882 (nginx)
      Tasks: 2 (limit: 1136)
     Memory: 3.8M
     CGroup: /system.slice/nginx.service
             ??27882 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
             ??27884 nginx: worker process

Also if you open a browser on your local machine such as chrome, you should find that if you go to http://server_ip – Where server_ip is the IP Address that you SSH’ed to, you should get an NGINX welcome page.

We also now want to run the below command to ensure that if the server reboots for any reason, the system knows that we want Nginx to be automatically started without any manual intervention

sudo systemctl enable nginx

Now we need a place to store our application which will be in the /var/www folder which Nginx will have just created – So use mkdir to create a directory on the server, replacing “your_domain” which what you want the folder to be called.

sudo mkdir /var/www/your_domain

Next we will create a new file within the Nginx sites enabled directory, this can be called anything but it makes sense to match it with the directory that you created within the “/var/www/” folder, within that we’ll paste in the block below, ensuring that you update “yourdomain” to your actual domain name.

nano /etc/nginx/sites-enabled/yourdomain

server {

        root /var/www/yourdomain/;

        index index.html index.htm index.nginx-debian.html;

        server_name yourdomain.com;

        location / {
                proxy_pass http://localhost:5000;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection keep-alive;
                proxy_set_header Host $host;
                proxy_cache_bypass $http_upgrade;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;
        }

}

Now we should be able to restart Nginx to apply our new configuration.

sudo systemctl restart nginx

At this point I will normally browse to “yourdomain.com” just to make sure you see an Nginx page, however it should be a “502 Bad Gateway” response as our .Net Core application is not yet actually installed on the server for Nginx to pass the request back to.

4 – Setup MySQL on Ubuntu 20.04 (Optional)

So not all applications will require a database, and even if you have a database it could well be something different such as Postgres or MongoDB – However if you are using MySQL as your database, you can follow this set to get it installed on Ubuntu as a service.

Firstly we need to add the MySQL repository to our server, so that we’re able to use APT to install the MySQL packages rather than having to build from source – You probably want to get the latest version of MySQL rather than the one below, you can do this by going here – Then click the download button, on the next page right click on the “no thanks, just start my download” link, and copy the link address, this you can replace with the URL we WGET below.

Now we will move into the temp directory, and download the files:

cd /tmp

wget https://dev.mysql.com/get/mysql-apt-config_0.8.20-1_all.deb

sudo dpkg -i mysql-apt-config*
sudo apt update
rm mysql-apt-config*

Now we have the package downloaded and installed we should be able to install the MySQL server via APT – Follow through the wizard that this pops up.

sudo apt install mysql-server -y

Now we want to ensure that MySQL is running as it should have automatically started once the install was complete, if it was you’ll see a running output similar to below.

sudo systemctl status mysql

mysql.service - MySQL Community Server
     Loaded: loaded (/lib/systemd/system/mysql.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2021-11-11 15:24:23 UTC; 15s ago
       Docs: man:mysqld(8)
             http://dev.mysql.com/doc/refman/en/using-systemd.html
    Process: 30003 ExecStartPre=/usr/share/mysql-8.0/mysql-systemd-start pre (code=exited, status=0/SUCCESS)
   Main PID: 30052 (mysqld)
     Status: "Server is operational"
      Tasks: 38 (limit: 1136)
     Memory: 360.0M
     CGroup: /system.slice/mysql.service
             ??30052 /usr/sbin/mysqld

Then we need to ensure that the MySQL Service is set to enabled, so that in the event of a server reboot the MySQL service will be automatically started. We also follow this up with the secure install command, which will take you through a few steps to clean-up the install and keep things secure.

sudo systemctl enable mysql
mysql_secure_installation

Finally check you can login using your root user

mysql -u root -p

5 – Github .NET Core Automated Deployments CI/CD

Create GitHub Secrets

Login to GitHub, navigate to your project, click secrets, and create the following:

• REMOTE_HOST – IP Address (or Hostname) of your VM
• REMOTE_USER – User (such as root) that you wish to login as
• REMOTE_SSH_KEY – The SSH Key file that you login to your VM with
• PASSPHRASE – The Password that protects the SSH Key file
• REMOTE_TARGET – The directory on the VM where your files should be copied to

Create Github Actions / Workflow Template

So at this point we have a Web Server (Nginx) pointing to our Service (.Net Core) and if needed for your application we also have a Database (MySQL) installed on the same server, now all we need to do is get the application built and installed on the server.

What we’re using for this is Github actions, basically every time that we check code into Github it will automagically build the application, and copy the resulting files to our server and restart the service as needed, this is continuous deployment – You can also have Github run other tasks such as Unit tests on your code during the deployment, to ensure it’s working and safe.

So login to Github and go over to the Actions tab on your repository and create a new work flow – There is a .NET workflow which you can select, or even just the “setup a workflow yourself” will do, as the full script you need is given in detail below.

Now you’ll see a text editor window, all the contents within this can be replaced with the following, however before you save there are a few changes that you need to make:

• Where you see “ServiceName” this needs to be replaced with the name of the service created earlier.
• Within the SCP Copy command you’ll see a Path, this path will be dependant on your application, and where it saves the binaries on a build. I normally take a best guess at it, then look in the GitHub action logs to see where it was actually saved, then update the actions file to match this. You can work it out, but this just seems easier.

The script has the following stages

• Checkout the latest code from “master”
• Perform a Dotnet Restore, Build, Run Tests and Publish
• Stop the service on the remote VM, so avoid issues (this is service affecting)
• SCP Copy the Published files from GitHub’s build server to our live server
• Start the service on the remote VM with the new application in place

The script is as follows:

name: .NET Core

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

jobs:
  Deploy:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - name: Setup .NET Core
      uses: actions/setup-dotnet@v1
      with:
        dotnet-version: 6.0.x
        
    - name: DotNet Restore
      run: dotnet restore
    
    - name: DotNet Build
      run: dotnet build --no-restore
      
    - name: DotNet Run Tests
      run: dotnet test --no-build --verbosity normal
      
    - name: DotNet Publish
      run: dotnet publish -c Release
      
    - name: Stop ServiceName Service
      uses: garygrossgarten/github-action-ssh@v0.6.3
      with:
        command: service ServiceName stop
        host: ${{ secrets.REMOTE_HOST }}
        username: ${{ secrets.REMOTE_USER }}
        passphrase: ${{ secrets.PASSPHRASE }}
        privateKey: ${{ secrets.REMOTE_SSH_KEY }}
      
    - name: Copy to Server via SCP
      uses: garygrossgarten/github-action-scp@release
      with:
        local: /home/runner/work/DemoApp/DemoApp/DemoApp/bin/Release/net5.0/publish/
        concurrency: 10
        remote: ${{ secrets.REMOTE_TARGET }}
        host: ${{ secrets.REMOTE_HOST }}
        username: ${{ secrets.REMOTE_USER }}
        passphrase: ${{ secrets.PASSPHRASE }}
        privateKey: ${{ secrets.REMOTE_SSH_KEY }}
      env:
        ASPNETCORE_ENVIRONMENT: Production
        
    - name: Start ServiceName Service
      uses: garygrossgarten/github-action-ssh@v0.6.3
      with:
        command: service ServiceName start
        host: ${{ secrets.REMOTE_HOST }}
        username: ${{ secrets.REMOTE_USER }}
        passphrase: ${{ secrets.PASSPHRASE }}
        privateKey: ${{ secrets.REMOTE_SSH_KEY }}

Once you are ready click “Commit” that will save this file via a GIT Commit into your repository – As this is just like any other “Commit” on this repository Github will actually automatically trigger the action you just created and run through the workflow, meaning this is a great way to test if your script is working.

So that’s all we need, any future commit such as from your IDE or Code Editor to the “master” branch will also run the same actions, which automatically build and deploy your application. I would suggest on the first few watching through the log to resolve any errors that could arise.

If you have any questions pop them in the comments below, and I’ll do my best to help answer them!

Clickhouse is a column-oriented database created by Yandex and open sourced, which supports real-time SQL queries for Online Analytic Processing.

It is designed from the ground up to support billions of rows and terabytes of data, but still return results to analytical queries in hundreds of milliseconds, even on fairly normal and commodity server hardware.

ClickHouse is quite commonly used in website analytics services, were you stream ingest events into a long-term data warehouse, but have the ability to quickly query data at a later point, to perhaps graph unique visitors, browser adoption, page performance etc.

Getting started is really simple, especially with Docker which is what we’ll go through in this guide.

1 – Setup Storage

Clickhouse persists it’s data to a physical disk, so while you can just run the docker image as is, it makes sense to define a permanent storage location for your data.

Here we create a folder to contain the docker files “clickhouse” within our home directory, and within that we create another folder called “dbfiles” which will simply contain the stored data – You can change these to match your preferred partitioning layout.

cd ~
mkdir clickhouse
cd clickhouse
mkdir dbfiles

2 – Create Docker Compose FIle

Next we need to create a Docker Compose file, simply put this is a file that will tell docker what image we want to run, where we want the data to be stored, and how we want the networking to be setup – This will go in our newly created folder, so just open the file up in a text editor like nano.

nano ~/clickhouse/docker-compose.yml

Then paste in the following, making any changes you need (if you changed the folder names in step one then you must reflect that here).

version: '3'

services:
  click_server:
    image: yandex/clickhouse-server
    ports:
      - "8123:8123"
    volumes:
      - ./dbfiles:/var/lib/clickhouse

  click_client:
    image: yandex/clickhouse-client
    entrypoint:
      - /bin/sleep
    command:
      - infinity

3 – Start and Connect to Clickhouse

Next we simply need to tell Docker that we want to run our compose file, that’s just a case of running docker compose, with the up command.

sudo docker-compose up -d

If this is the first time running a Clickhouse server on this host you’ll see it start to download the image files from the internet, which could take a few minuets – Once that’s done you can connect to the Clickhouse server using the command:

# docker-compose exec click_server clickhouse-client


  ClickHouse client version 21.8.10.19 (official build).
  Connecting to localhost:9000 as user default.
  Connected to ClickHouse server version 21.8.10 revision 54449.
  66c76cb18f7b :)

4 – Create a Database and Test

Below are some examples of how we can create a database, tables, insert data and perform some basic selects – If you’ve ever used MySQL or another SQL based database before, this will all look very familiar.

Create and Use a Clickhouse Database

Just as you would in any other SQL database, there isn’t anything special to consider when creating a Clickhouse database – Simply use the “create” command to generate a new database, and “use” to select a database.

66c76cb18f7b :) create database pingbin;

CREATE DATABASE pingbin

Query id: b648f3a8-ccf4-43a0-8e25-da881ce9196b

Ok.

0 rows in set. Elapsed: 0.025 sec.


66c76cb18f7b :) use pingbin

Create a Clickhouse Table

Again creating a new Clickhouse Table is fairly simple, and very similar to how you create any other SQL database table – One thing you should pay attention to is to how you partition and order your data, here we use the date, as each day is granular enough to allow good partitioning, and the order is going to be on all of our queries.

CREATE TABLE visits (
 Id UUID,
 EventDate DateTime,
 DomainId UUID,
 Path String,
 Referrer String,
 OperatingSystem String,
 OperatingSystemVersion String,
 CountryCode String,
 Browser String,
 BrowserVersion String,
 ScreenWidth UInt16,
 ScreenHeight UInt16
) 
ENGINE = MergeTree()
PARTITION BY toYYYYMMDD(EventDate)
ORDER BY (EventDate);

Insert and Select from a Clickhouse Table

Finally we will insert an example row, again this is extremely similar to any other SQL database, just ensure the order of your data matches the column order.

INSERT INTO visits VALUES (
    'd9c544bd-ec6c-4b58-b34d-b24cb51c0904',
    '2021-02-03 00:01:01',
    'd9c544bd-ec6c-4b58-b34d-b24cb51c0911',
    '/domains',
    '',
    'Windows',
    'Windows 10.101.1',
    'GB',
    'Chrome',
    'Chrome 123',
    1200,
    600
);

Then here we select that row back out of the database.

66c76cb18f7b :) select * from visits

SELECT *
FROM visits

Query id: 74a724a1-8b33-4130-8c26-fcb0bdc9f0c3


? d9c544bd-ec6c-4b58-b34d-b24cb51c0904 ? 2019-01-01 00:01:01 ? d9c544bd-ec6c-4b58-b34d-b24cb51c0911 ? /domains ?          ? Windows         ? Windows 10.101.1       ? IM          ? Chrome  ? Chrome 101001  ?        1231 ?          500 ?

1 rows in set. Elapsed: 0.012 sec.

Hopefully that was helpful, we’ve tested the above process on both Windows and Linux (Ubuntu) so it should work fine for you, however if you have any queries or issues just let us know and we’ll try to help out.

One thing to mention is that you probably want a minimum of 4GB RAM free to run Clickhouse, and enough storage space to obviously hold the data that you plan to load into it, however it does compress the data quite well in comparison to other databases.

After a recent Chrome update it seems to be deciding that it wants control of them buttons while it’s got media playing – So I would open up a Youtube video in Chrome, click Pause on the keyboard media keys, I was expect the background music to stop, but instead the Youtube video would pause… Not idea!

There’s a fix!

1 – Open up chrome and put the below in your address bar at the top, and hit enter/return.

chrome://flags/#hardware-media-key-handling

2 – You should see a “Hardware Media Key Handling” setting there, change this to Disabled

3 – Restart Chrome

Your back to normal now!

Overview

This is going to be a quick guide on how to setup VPN access on your Cisco router (in my case a Cisco 887 router with VDSL), for remote clients to access your network and get access to the local resources. There’s a few different ways of doing this however we’re going to use IPSec, mainly because it’s more secure than the alternatives and doesn’t require any third party clients to get it working (most of the time).

The guide will assume you’ve already got your LAN (VLAN1) and WAN (PPPoE/A on Dialer1) setup and working, also it assumes you have some Cisco knowledge to actually get the commands applied in the right places as I wont be covering the basics.

If you need a base configuration for a Cisco 887 look at the post here, otherwise jump straight into it below!

1) Enable Authentication

So the first part is to enable authentication on the router so that we can create users and have the VPN authenticate against these, you could also use an external radius server however if you’ve only got a few users this is going to be simpler to manage

aaa new-model
aaa session-id common

aaa authentication login default local
aaa authentication login vpn_xauth_ml_1 local
aaa authentication login sslvpn local
aaa authorization network vpn_group_ml_1 local 

username vpn_username password 0 vpn_password

2) IP Address Pool

Next we need to create an IP pool that we’ll use to give the VPN clients unique IP addresses that appear to be on the LAN (VLAN1), the second step is to ensure that we don’t hand out these same IP’s as part of the normal DHCP process.

ip local pool vpn_client_pool 192.168.0.100 192.168.0.109
ip dhcp excluded-address 192.168.0.100 192.168.0.109

3) Split Tunnel

Now normally when a client to connects to our VPN we want it to send all traffic to us for the LAN, there’s usually no point in sending internet or DNS traffic to us if they already have an internet connection, we do that with an access list.

Basically the below is saying ‘any’ of the clients have access to ‘192.168.0.0/24’, you should be able to modify to your specific requirements.

ip access-list extended vpn_resources
 permit ip 192.168.0.0 0.0.0.255 any
!

4) IPSec

IPsec uses two different phases for user authentication and traffic encryption, therefore we need to create two different policies. There are more secure settings than what I’m using in the policy below, however you’re realistically going to have more compatibility problems as you tune up these, and the below are still very secure for most installs.

crypto isakmp policy 1
 encr 3des
 authentication pre-share
 group 2
!
crypto isakmp policy 2
 encr 3des
 hash md5
 authentication pre-share
 group 2
!

5) VPN Group

Now we need to define the group, the group name and group key that you pick here will need to be also entered on all of the clients that are using the VPN (laptops/iphones etc…), so you want to pick something secure but something that you also don’t mind disclosing to people with VPN access.

In the below configuration my group is ‘oracle’ and we’re using a shared password of ‘qwerty’, you should also notice this is where we’re referencing the ip address pool that these clients will be given, and the access list that defines where they’re allowed to go within our network ‘vpn_resources’

(If you want to redirect the client’s DNS queries you could also do that here with the ‘dns’ setting, however theres usually not much point in that unless you have some kind of intranet.)

crypto isakmp client configuration group oracle
 key qwerty
 pool vpn_client_pool
 acl vpn_resources
 max-users 10
!

So the above configuration was mostly for Phase 1 (ISAKMP) of the tunnel, really this is concerned with securely authenticating the users and defining how were going to configure them on the network once they’re connected.

Naturally that brings us onto Phase 2 (IPSec), which is how the already authenticated users are going to securely encrypt there traffic between the router and client. First we’ll setup a transform set and bind that to an IPSec profile

crypto ipsec transform-set vpn_transform esp-3des esp-sha-hmac 
!
crypto ipsec profile vpn_profile
 set transform-set vpn_transform
!

6) Virtual Tunnel

Now we need somewhere on the router that clients can actually bind there internal IP to, for example the ip route and ARP table on the router needs to know where to send that traffic, this is a ‘virtual-template’. The configuration is simply saying our virtual-template2 is part of the IPSec profile we just created and is on the VLAN1 internal network.

interface Virtual-Template2 type tunnel
 ip unnumbered Vlan1
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile vpn_profile
!

Now the last part should be to glue our VPN group, how we want to authenticate users and virtual template configuration together using the ISAKMP profile.

crypto isakmp profile vpn_ike_profile
   match identity group oracle
   client authentication list vpn_xauth_ml_1
   isakmp authorization list vpn_group_ml_1
   client configuration address respond
   virtual-template 2
!

7) Testing Clients

The final step is to go over to one of your clients and actually try the VPN connection, below are the five bits of information that these clients will require a minimum, most will dynamically pick up the rest of the required information.

Clients like an iPhone (shown at the right) have a built in client, however if yours doesn’t go over to the cisco website and download the ‘Cisco VPN Client’, it’s currently available for most operating systems like Windows, Linux, OSX and Solaris.

• Public IP or DNS Name – vDSL Dialer1 Public IP
• Group Name – oracle
• Group Pass – qwerty
• User – vpn_username
• Pass – vpn_password

Cisco IOS has a build in Command Scheduler called KRON, with very similar functionality to the Linux CRON service many will be familiar with, we are able to use this scheduler to run customizable tasks on a predefined interval – Within this guide you can learn how to schedule common IOS commands, or sequences of commands, to perform useful tasks, such as backups of configuration or daily reboots of your Cisco device.

It’s a little known feature of Cisco devices, however KRON actually first appeared in IOS 12.3(1) back in 2008, so if you check the running software on your device and find this version or higher, you should be good to go.

Cisco Scheduled Auto Configuration Save

One of the most common uses for the scheduler, is to defined a daily configuration save of the router (or switches) running configuration that’s stored in Volatile RAM, over to the startup configuration file which is stored in VNRAM – This helps to ensure that device configuration is likely not going lost if an engineer forgets to manually save the configuration after making some changes, and there’s an unexpected reboot or power loss to the device.

The example below is fairly simple, first we create a “policy-list” which should just be thought of as a script, for example the bash script part if this was a Linux device using Cron – Here we are just running “cli write” which is the command to save the configuration, and giving the script a name.

An important note here is that you must use a none interactive command – Basically your command cannot require user input otherwise it will not work, that is why the script is using “cli write” and perhaps not the more commonly used “copy run start” command.

The second part is setting up the occourance, which is the schedule it’s self, here it’s configured to run at 04:00 every day and recur until the schedule is manually removed. The Akron occourance quite simply points to the script that was created above.

kron policy-list daily-save-config
 cli write
!
kron occurrence daily-save-config at 4:00 recurring
 policy-list daily-save-config
!

You might also want to check that everything is as you expect, to do that the most useful display command is “show kron schedule”

Cisco Scheduled Reboot

This may seem like a strange command, however I’ve seen a number of branches/houses with DSL based connectivity perform a daily reboot at night, in attempt to force a re-sync of the line out of business hours.

Again the process is as you saw above, first we create a kron policy called “reloadrouter”, then within this we simply define that we wish the router to invoke a “cli” command which is “reload”

kron policy-list reloadrouter
 cli reload
!

Now we’ve got a simple script defined the router knows what we expect it to do, the next part is to let is know when we would like that to be run, so again within Cisco IOS we must create an occurrence of the script policy, with a time that we want it to “occur”

The below will run our reloadrouter policy at 04:00 AM, and reoccur every day.

kron occurrence reloadrouter at 4:00 recurring
 policy-list reloadrouter
!

Cisco Daily Debug Removal

Another useful trick on Cisco routers is to perform a daily removal of the debug commands, without this it’s possible that someone will forget that debug was enabled, and leave it running for weeks or months at a time. Best case this could just be an annoyance of filling up your local log storage, or syslog server, however it could actually be much worse and cause performance issues on the device.

In the below we simply have a daily command running at 01:00 AM each morning to remove all debug.

kron policy-list daily-un-debug
 cli undeb all
!
kron occurrence daily-un-debug at 1:00 recurring
 policy-list daily-un-debug
!

Cisco Daily TFTP Configuration Backup

Here is another quick example, where if you don’t have a centralised configuration management system in place, you could have a quick script running on the Cisco device each day to copy it’s startup (or running) configuration off to a remote server.

kron policy-list config-backup
cli show startup-config | redirect tftp://10.1.1.1/bkup.cfg
!
kron occurrence config-backup at 1:00 recurring
 policy-list config-backup
!

As a final hint its always good to remember that your device will run these based on the device time, so if you don’t have NTP in place to keep your Cisco device time insync and accurate, you may want to look into that first.

Overview

After spending quite a bit of time getting my Cisco VDSL router working with PPPoE I though others might benefit from an example configuration, please read through and tune the configuration to match your requirements.

 
Basically this will setup the vDSL connection and obtain an IP address from your ISP using PPPoE CHAP authentication, the 192.168.0.0/24 range will be used on the inside network and DHCP will handout IP’s within the range 192.168.0.6-99/24, the router will take the address 192.168.0.1 and perform PAT based NAT on any outbound traffic.

Configuration

no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
service internal
!
hostname HOME-GW-1
!
boot-start-marker
boot-end-marker
!
!
logging buffered 4096
enable secret {PASSWORD-GOES-HERE}
enable password {PASSWORD-GOES-HERE}
!
aaa new-model
!
!
aaa authentication login default local
!
!
!
!
!
aaa session-id common
memory-size iomem 10
clock timezone gmt 0 0
clock summer-time BST recurring last Sun Mar 2:00 last Sun Oct 3:00
crypto pki token default removal timeout 0
!
!
no ip source-route
!
!
!
ip dhcp excluded-address 192.168.0.0 192.168.0.5
ip dhcp excluded-address 192.168.0.100 192.168.0.255
!
ip dhcp pool 10
 import all
 network 192.168.0.0 255.255.255.0
 ! Change to your ISP DNS
 dns-server 8.8.8.8 4.2.2.2 
 default-router 192.168.0.1 
!
!
ip cef
! Change to your ISP DNS
ip name-server 8.8.8.8
ip name-server 4.2.2.2
ip inspect WAAS flush-timeout 10
ipv6 cef
!
!
!
archive
 log config
  logging enable
  logging size 500
  hidekeys
username {username} secret {password}
!
!
!
!
controller VDSL 0
 operating mode vdsl2
 modem customUKAnnexM
 modem customUKAnnexA
 modem UKfeature
!
ip ssh version 2
! 
!
!
!
!
!
bba-group pppoe global
!
!
interface Ethernet0
 no ip address
 pppoe-client dial-pool-number 1
!
interface ATM0
 no ip address
 shutdown
 no atm ilmi-keepalive
!
interface FastEthernet0
 description Link-to-Dist-Switch
 no ip address
 duplex full
 speed 100
!
interface FastEthernet1
 no ip address
!
interface FastEthernet2
 no ip address
!
interface FastEthernet3
 no ip address
!
interface Vlan1
 ip address 192.168.0.1 255.255.255.0
 ip nat inside
 no ip virtual-reassembly in
 ip tcp adjust-mss 1452
!
interface Dialer1
 description vDSL
 mtu 1492
 ip address negotiated
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip nat outside
 no ip virtual-reassembly in
 encapsulation ppp
 dialer pool 1
 dialer idle-timeout 0
 dialer-group 1
 ppp authentication chap pap callin
 ppp chap hostname {ISP-USERNAME-HERE}
 ppp chap password 0 {ISP-PASSWORD-HERE}
 ppp pap sent-username {ISP-USERNAME-HERE} password 0 {ISP-PASSWORD-HERE}
 ppp ipcp dns request accept
 ppp ipcp route default
 ppp ipcp address accept
 no cdp enable
!
no ip forward-protocol nd
no ip http server
no ip http secure-server
!
ip dns server
ip nat inside source list 10 interface Dialer1 overload
!
access-list 10 permit 192.168.0.0 0.0.0.255
access-list 10 remark nat-pool
access-list 23 permit 192.168.0.0 0.0.0.255
access-list 23 remark vty
access-list 23 deny   any log
dialer-list 1 protocol ip permit
!
!
!
!
!
!
!
ipv6 access-list ipv6_deny
 deny ipv6 any any
!
ipv6 access-list V6-FILTER
 permit icmp any any
 deny ipv6 any any log
banner login ^CC
THIS IS A PRIVATE SYSTEM. UNAUTHORISED ACCESS IS NOT
PERMITTED AND OFFENDERS ARE LIABLE TO PROSECUTION.

YOUR IP HAS BEEN LOGGED AND AN ALERT GENERATED
^C
!
line con 0
 logging synchronous
line aux 0
line vty 0 4
 access-class 23 in
 ipv6 access-class ipv6_deny in
 transport input telnet
 escape-character 3
!
scheduler max-task-time 5000
ntp server {YOUR-NTP-Server}
end

ShellSock – Patching

Unless you’ve been under a rock for the last few days you’ve probably heard about the new Bash exploit (CVE-2014-6271) ‘ShellShock’ that allows remote code execution through bash, because of the amount of servers and applications using the bash service it’s a fairly big deal in the security world.

How To Patch

Here’s a few simple commands to get your CentOS servers patched, please for your sake do this ASAP.

# Check if vulnerable
env x='() { :;}; echo Vulnerable system'  bash -c "echo Testing..."
 Vulnerable system
 Testing...
#

# If you need to access the web via a proxy, add that here.
nano ~/.bash_profile
export http_proxy=http://192.168.1.123:3128

# Apply the patch
yum update bash -y

# Remove proxy (if used
nano ~/.bash_profile
# export http_proxy=http://192.168.1.123:3128

# Check if vulnerable
env x='() { :;}; echo Vulnerable system'  bash -c "echo Testing..."
 Testing...
#

Any problems or questions, please leave a comment.

After the bash exploit ‘shellshock’ was released a few days ago I’ve been going around my servers and applying the required patches, however after doing a ‘apt-get update’ on one of the web servers PHP based requests were no longer working.

Having a look in the Nginx error logs I found that the issue appeared to be at the PHP-FPM layer of the server (which I kind of expected), as it did have an update included in the bulk install and it was PHP that seemed to be broken, heres an example log:

2014/09/26 05:24:28 [crit] 26963#0: *19 connect() to unix:/var/run/php5-fpm.sock failed (13: Permission denied) while connecting to upstream, client: 46.226.191.96, server: subnet.im, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "subnet.im"
2014/09/26 05:24:29 [crit] 26963#0: *19 connect() to unix:/var/run/php5-fpm.sock failed (13: Permission denied) while connecting to upstream, client: 123.226.191.96, server: subnet.im, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "subnet.im"
2014/09/26 05:24:30 [crit] 26963#0: *19 connect() to unix:/var/run/php5-fpm.sock failed (13: Permission denied) while connecting to upstream, client: 123.226.191.96, server: subnet.im, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "subnet.im"
2014/09/26 05:24:32 [crit] 26964#0: *28 connect() to unix:/var/run/php5-fpm.sock failed (13: Permission denied) while connecting to upstream, client: 123.226.191.96, server: subnet.im, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "subnet.im"
2014/09/26 05:24:38 [crit] 26964#0: *37 connect() to unix:/var/run/php5-fpm.sock failed (13: Permission denied) while connecting to upstream, client: 123.226.191.96, server: subnet.im, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "subnet.im"

After some digging around I found that this was caused by a PHP bug fix #67060 (linky here), the bug was basically providing possible privilege escalation on the web server which they’ve fixed, however this changes some of the permissions stopping Nginx connecting to the required stocket used for PHP processing.

The Fix

Fortunately the fix is fairly simple, edit the PFP-FPM configuration.

 nano /etc/php5/fpm/pool.d/www.conf

Add in these three lines, they are probably already there and just need the comment marks removing.

listen.owner = www-data
listen.group = www-data
listen.mode = 0660

Finally re-start the PHP-FPM service and you should be back in business.

sudo service php5-fpm restart

TL,DR; – Go to Installing Squid

Yum is a great package manager for CentOS that is the secret envy of every Windows system administrator on the planet, however there will come a time when you attempt a “yum update” or “yum install tcpdump” to find out there is a problem with internet access from your server.

90% of the time you’ll probably find a network issue or someones messed up the DNS resolver configuration, however in some instances the server will legitimately have no internet access and setting up this access is either not allowed or high innocent.

Recently I worked on a server with two network connections, one to the management network and another to a VoIP signalling/media network, in this setup the default gateway was configured via the VoIP network as that’s the mission critical services, all the management elements had static routes via the management interface gateway. The problem was the VoIP network was internal and had no internet access available where as the management network did. Placing a static route for every possible Yum repository and mirror obviously isn’t an option and neither was switching around the network configuration, so here comes the Proxy.

The concept of a proxy is fairly simple, we’re going to tell Yum that all of it’s traffic should be sent to a specific IP address on a specific port, this IP address will be on a server with internet access and will have the Squid proxy installed and listening on that port for inbound connections. Assuming the access lists on the proxy are configured correctly this will then route that traffic to the internet and back on behalf of the originating server, therefore giving the illusion of internet access for Yum, simple!

Initialling Squid

So you need to find a server on your network that has IP connectivity to the internet and to your other server that doesn’t have internet access, this is where the proxy (Squid) will reside.

First step use Yum to install the Squid application on this server, and then ensure that it’s going to start at boot.

yum -y install squid
chkconfig squid on

Now you need to define which client IP addresses are permitted to use your proxy, in our case this range should include the IP of the client that doesn’t have internet access. So edit the squid configuration as below replacing the IP range as per your network.

nano /etc/squid/squid.conf
acl allowed_clients_acl src 192.168.0.0/24
http_access allow allowed_clients_acl

Now restart the Squid service to apply the configuration changes:

service squid restart

It’s always worth checking that Squid is actually running and listening on the correct network port using netstat

netstat -lnutp | grep 3128
tcp        0      0 0.0.0.0:3128                0.0.0.0:*                   LISTEN      20653/(squid)

Client/Yum configuration

So our Squid proxy server should be working now, the next step is to actually configure the clients to use this server. Simply in the users (in this case root) bash profile were going to specific an environment variable that yum will pick up on, so edit that profile text file:

nano /root/.bash_profile

Then just paste in this line, replacing the IP address with your Squid server (you can also use a hostname).

export http_proxy=http://192.168.204.251:3128

Bingo – Try some yum commands on the server and you should be in business!

Any problems leave a question in the comments

However there’s always cases where that options not available for some reason or another, in these cases you can use a setup like Kurt’s, where he decided to build a passive bandwidth monitor (even through the router in his pictures does support SNMP?!).

See a basic video of it in operation here:

The basic setup consists of a passive network tap; This is basically just a fancy way of saying that you’ve cut into the pairs of a Cat5e network cable and added in an extension of the pairs to your own device. The device that you add in should be doing nothing other than monitoring, so that it’s not transmitting any data on to the cable that would confuse the other two host which assume their are directly connected to each other with no other hosts on the network segment. The limitation of this setup is you need physical access to the cable, and due to the nature of high speed ethernet it would only work on 100Mbps connections or less.

The electronic brains behind the setup is a ENC624J600 chip to interface with the ethernet layer, chosen because of it’s raw ethernet functionality, this was connected up to an Atmega128 using the SPI interface which would run the core code to count packets and plot on the LED display.

To have a look at Kurt’s full write up on the project, head over to here.