PostgreSQL is one of the most used open source database solutions besides MariaDB / MySQL. Even though they have some similarities, PostgreSQL is based on a object-relational database management system while MariaDB and MySQL are relational database management systems. This article is about how to save a PostgreSQL output. While you can use the command mysqldump to dump your MariaDB or MySQL database, saving an output with PostgreSQL is a little bit different and doesn’t require an extra tool.
Switch to the database
First and foremost we have to change / go to the database. In Linux you also have to be the PostgreSQL system user in order to work with the database. To change the user just use sudo:
user@machine:~$ sudo -u postgres /bin/bash
You are now the user postgres. You can see this at the beginning of your command line. Instead of your username you can now see postgres@ at the beginning of the line. As next we use the psql command to switch into the actual database we want to dump:
postgres@machine:~$ psql database
Type "help" for help.
You are now connected to the database. Don’t forget to replace database with the desired database you want to connect to.
Save a PostgreSQL output
To finally save an output you can use normal SQL statements which are returning your desired value and wrap this command within a COPY statement. The following example saves the output of an PostgreSQL statement in the file output.txt which will be located in /tmp:
database=# COPY (select firstname, lastname from user_table) TO '/tmp/output.txt';
Save a PostgreSQL output as CSV
You can also define in which format the output should be saved. You can save the output as a CSV file so that you will be able to easily work with the output within LibreOffice or MS Office for example. The following example saves the same output as in the example above, but uses CSV with semicolons as a format:
database=# COPY (select firstname, lastname from user_table) TO '/tmp/ouput.csv' (format csv, delimiter ';');
Exit database / psql command
To exit the database access and therefore the running psql command, simply enter \q to quit.
As you can see, saving / dumping PostgreSQL output directly into a text file even as a CSV file is a great feature. No extra tools needed. But PostgreSQL comes with much more than just dumping output to test and CSV files. Even the COPY command can be modified with a lot of other different settings. A good book about PostgreSQL is PostgreSQL: Up and running by Regina Obe and Leo Hsu. It covers a lot of other things besides dumping output from PostgreSQL as well.
Setting up a 7 Days to Die server under Linux isn’t as difficulty as you may think. The Steam developer Valve is providing a tool which makes it easier, even for people who aren’t that familiar with the Linux command line. This article is covering how you setup your own 7 Days to Die server under a Ubuntu or Debian installation.
About 7 Days to Die
7 Days to Die is a zombie apocalypse survival crafting game which has been initially released in December 2013. The game is still in a „Early Access“ stage. 7 Days to Die is similar to Minecraft in the way it is played, but provides better graphics and a different scenario. There are also some quests included like treasure hunting. In the latest version (as of written in June 2018) the developer The Fun Pimps also integrated vehicles into the game. Like in Minecraft, the real fun with 7 Days to Die starts when you start playing with friends. Surviving, building and creating in a random generated world can bring you hours of fun and a long lasting motivation to go on in the things you wanna achieve.
On a freshly Debian or Ubuntu installation, we need to install some requirements in the first place. With the following command we will update the package repositories and install the necessary requirements:
The Steam command line tool is only available as a 32-Bit program. As of today most of the systems are 64-Bit based. Ubuntu for e.g. isn’t even supporting 32-Bit anymore. If you’re running an 32-Bit system, you can skip this part. To find out if you have a 32-Bit system installed, just issue the following command on your system:
If the output of this command is i386 or i586, you have a 32-Bit system. If it’s x86_64 you’re using a 64-Bit system. In this case you have to issue the following two commands as well:
This installs the lib32gcc1 file which is a 32-Bit library. This library is needed by the Steam command line tool. If this library isn’t installed, the following commands will fail.
Download and extract Steam
As next, we acquire the Steam command line tool for Linux machines in order to download the server files via the Steam network. Before that we create a separate folder (which is called steamcmd) were we are going to download the Steam command line tool to:
user@machine:~$ mkdir steamcmd
user@machine:~$ cd steamcmd
user@machine:~/steamcmd$ wget http://steamcdn-a.akamaihd.net/client/installer/steamcmd_linux.tar.gz
The wget command is now downloading the Steam Linux command line tool. After the download is finished, we can extract this tool (it is compressed right now) like this:
user@machine:~/steamcmd$ tar -xvzf steamcmd_linux.tar.gz
Updating the Steam tool
You can now start updating the Steam tool. Execute the following command to start the update:
This process will take some time. In the meanwhile, you will see a lot of output on the console like this:
Redirecting stderr to '/home/user/.steam/logs/stderr.txt'
ILocalize::AddFile() failed to load file "public/steambootstrapper_english.txt".
[ 0%] Checking for available update...
[----] Downloading update (0 of 13.028 KB)...
[ 0%] Downloading update (38 of 13.028 KB)...
[ 0%] Downloading update (38 of 13.028 KB)...
[ 0%] Downloading update (38 of 13.028 KB)...
[ 0%] Downloading update (38 of 13.028 KB)...
When the process is finished you will see a output which looks like this:
Steam Console Client (c) Valve Corporation
-- type 'quit' to exit --
Loading Steam API...OK.
The last line Steam> tells you that the Steam command line tool is actually opened and Steam waits for you to enter a command.
Login into Steam
When using the Steam command line tool, you have to login just like with the graphical desktop version. Enter the command login followed by your Steam username to login. Steam will then ask you for your password and Two Factor Authentication (if enabled). When you enter your password there will be no input shown. But this is normal, just like in almost every Linux / UNIX software:
Steam> login <USERNAME>
Logging in user '<USERNAME>' to Steam Public...
Enter the current code from your Steam Guard Mobile Authenticator app
Logged in OK
Waiting for user info...OK
Download and install the 7 Days to Die server files
Now that you’re logged in, you can finally start downloading and installing your 7 Days to Die server. With the first of the following two commands we enforce Steam to install the 7 Days to Die server files into the directory 7dtd_server. The second one is starting the actual installation process of the server files. The number 294420 is the ID for the 7 Days to Die server files:
This will download the latest BETA experimental branch the developers are providing to the public audience. You can see again an output which will show you the actual progress:
Update state (0x5) validating, progress: 2.19 (75656327 / 3459239207)
Update state (0x61) downloading, progress: 0.21 (7340032 / 3459239207)
Update state (0x61) downloading, progress: 1.02 (35228112 / 3459239207)
Update state (0x61) downloading, progress: 2.75 (95064875 / 3459239207)
The app_update commands can take even longer than the Steam update process. It basically depends on your internet connection speed. After this command was successful, you will get yet again another message about it:
Success! App '294420' fully installed.
You can now quit the Steam command line tools by simply entering quit. Congratulations, you successfully downloaded and installed a 7 Days to Die server under Linux.
Configuring your server
You have a lot of options to configure your 7 Days to Die server to your wishes. The file to do so is the serverconfig.xml which is in the same directory as your 7 Days to Die server files. So change into the 7 Day to Die server directory:
user@machine:~/steamcmd$ cd 7dtd_server
Within this directory, there is already an example serverconfig.xml. While this file should work already, you should take at least some tweaks. To edit this file you can use the editor nano:
With CTRL+W you can search for a string. With CTRL+O you can save the file. And with CTRL+X you close the editor. The following parameters are a suggestion how you should modify your serverconfig.xml. [table id=1 /] You can always come back and change the parameters to your desire. However, you always have to restart the server after each change. For a full list of all possible values, check out this list.
Starting the server
Puh, lot of stuff right? But now the time has come to start your server. In order to have your server running constantly, you have to use screen. screen is a tool which runs programs even while you logged out. But first, ensure that you’re still in the 7dtd_server directory and enter the following commands:
Your server will now start. This can take up to 5 minutes. You get no output when the server is ready. If you want to know more about what is hapenning, take a look at the output.log file within your 7dtd_server directory. To close the screen session (and therefore let the server run in the background), press CTRL+A followed by the D key for detaching. You can now close your remote session to your server without shutting down your 7 Days to Die server itself. If you want to attach to the screen session again, simply enter this command:
user@machine:~$ screen -r 7dtd
You can now start 7 Days to Die on your desktop / gaming machine, click on Connect To Server and enter either die IP address / name of your server (FQDN) and click on the connect symbol or search for your server name in the upper left (if you set your server to public at the step before):
If you can’t connect at this point, you may have to check your firewall or the firewall on your server (if you use one). On default, the 7 Days to Die server listens on port 26900. This port has to be accessible from the internet.
Stopping the server
To stop your server, simply resume your screen session like this:
user@machine:~$ screen -r 7dtd
And press CTRL+C afterwards. It can take a few seconds up to a minute before the server shuts down.
How to become an admin?
In order to become an admin, you have to tell your server your Steam ID. Otherwise the server can’t decide which player really should get admin rights. To get your Steam ID, simply open Steam, click on your profile and copy the long number within the URL:
On your server, change into the following directory and create a file called serveradmin.xml. Open it afterwards with an text editor (we use nano again in this case):
user@machine:~$ cd $HOME/.local/share/7DaysToDie/Saves/
user@machine:~/.local/share/7DaysToDie/Saves$ touch serveradmin.xml
user@machine:~/.local/share/7DaysToDie/Saves$ nano serveradmin.xml
Don’t forget to change the value 12345YourSteamID to your Steam ID! Press CTRL+O to save and CTRL+X to close the file. Afterwards, stop and start the 7 Days to Die server and that’s it. You could even create moderators and give each of them specific rights. However, this would definitely burst this article. If you want to know more about the possible rights management on a 7 Days to Die server, check out this link.
Last words …
As you can see, with a little bit of work you can setup your own 7 Days to Die server on a cheap Linux VPS for example. Of course you could also go with a hosted one and don’t bother about all the setup stuff, but this is way more costly. And if you’re interested in working with Linux machines, this is a good way to learn a little bit about how to maintain and setup server software under Linux in general. If you have any comments, wishes or notes, please let me know down below in the comments.
A lot of people who are running a rented Linux (v)Server are interested in creating a Counter-Strike: Global Offensive server. Creating a CSGO server under Linux is rather easy, Valve really did their homework here. The following short tutorial will give you the needed instructions to create a Counter-Strike: Global Offensive Server under Debian, Ubuntu or openSUSE:
1. Create a new user
First of all, you should really create a new user in your Linux system. The reason for that is simple: security! If your main user, or even your root user, is running the CS:GO server and is hacked later on, the hacker maybe is in the position to get access to the system behind the Server. With that being said, he may be able to get full access to the shell and he may be able to manipulate the system. To create new account on your Debian, Ubuntu or openSUSE system, you have to enter the following commands:
So, the first commands creates a new user, called csgosrv. The seconds commands sets a new password for this user. The password you enter here will not be prompted. The third command creates a new directory called csgosrv under the directory /home. This will be the standard home directory for the user csgosrv we’ve created before. The fourth and last command sets the owner to the created user csgosrv and the group owner of the created csgosrv home directory to users.
2. Install needed dependencies
In this step we need to download the needed libraries in order to get the Steam command line tool working. If these libraries / tools are not installed, the Steam command line client (provided by Valve), will fail to start. If you’re on a 64-Bit Debian or Ubuntu system you have to enable the i386 architecture in the first place. This is needed because the server software is written for the 32-Bit architecture. If you’re on a 32-Bit Ubuntu or Debian, you can skip this command:
root@server:~# dpkg --add-architecture i386
The following two commands are needed for 32-Bit and 64-Bit systems. They will update the repository information and install the needed libraries:
If you’re on a openSUSE system, the commands are doing the same, but the syntax is different. The following two commands are updating the package repository and installs the needed libraries on a openSUSE system:
Now, that you have installed all the needed libraries, we can go on and start downloading and installing the server software.
3. Download Steam
Downloading the Steam command line tool is very easy. You can always get it directly from Valve. But before we start downloading the client, we should change to the beforehand created user csgosrv. We can do this with the following command:
root@server:~# su - csgosrv
As an alternative you could close your SSH session and reconnect with the user csgosrv. Now that we’re working with the right user, it’s time to download and extract Steam:
csgosrv@server:~$ mkdir steam
csgosrv@server:~/steam> cd steam
csgosrv@server:~/steam> wget http://media.steampowered.com/client/steamcmd_linux.tar.gz
csgosrv@server:~/steam> tar xfvz steamcmd_linux.tar.gz
So, the first two commands are creating a new directory, called steam, and directly changed into it with the help of the cd command. The third command is downloading the Steam CMD tool with the help of the tool wget. The fourth and last command extracts the so downloaded .tar.gz archive. After you’ve done this steps successfully you can go on and download the CS:GO server software.
4. Setup Steam and install CS:GO server files
This command will update the steam command line tool and installs the application „740“ which is the Counter-Strike: Global Offensive server. For now you don’t need to have your steam credentials ready. You can update steam and install the server software as an anonymous user:
This command will take some time and the so downloaded server software needs round about 15 GB hard disk space. The Server software will be installed in the directory /home/csgosrv/steam/csgo_server.
5. First start of the CS:GO server
Now that you have successfully downloaded and updated the Counter-Strike: Global Offensive server, we can do a test run. With the following command we can start the server with the mode Classic Casual and the Mapgroup mg_bomb which includes the old bomb spot maps like de_atztec or de_dust / de_dust2:
You will now get a lot of output. This is normal and shows you, that the software is working. However, at the end of all the lines you will find a message like this one:
* No Steam account token was specified. *
* Logging into anonymous game server account. *
* Connections will be restricted to LAN only. *
* To create a game server account go to *
* http://steamcommunity.com/dev/managegameservers *
Basically this message means that your server is not registered at Vale. As long as you don’t register your server at Vale, you will only be able to connect to the server via LAN, not via the internet. It will never be an official server played on. To make your server ready for the internet, you have to go on with the next step (you can terminate the actual running session with an CTRL+C combination).
6. Make your server an official registered one
To register your CS:GO server at Valve and make it ready for internet play, you have to register the server directly at Valve. To do so, visit the following link: Steam Server management. Login with your steam credentials (if you haven’t already) and enter the number 730 as the App ID in the first text box. The second text box can be filled with whatever you want. It’s just a comment field. For e.g. if you have more than one server you could write down the hostname here so that you can always directly see which token belongs to which server. Click on Create to get your Token: After you clicked on Create you will see your token for your server. The token can only be used on one server for one active session. You can’t use the token for multiple servers at the same time. You have to create a new token for each of your servers. Now that you have created your token, you can use it to start the server as an official CS:GO server with the following command:
Of course you have to replace the YOURTOKEN with the token you’ve created before. If there is no firewall blocking the traffic, you should now be able to find your server via the CS:GO server browser or connect directly via the hostname / IP to it.
7. Start the CS:GO server in the background
You may already noticed, that the CS:GO server stops running when you close the SSH connection. This is, because the CS:GO server software needs an active terminal / SSH session to go on running. However, there is a tool which is called screen. If you’ve followed this tutorial, you already have installed screen at the first steps. The following commands starts the CS:GO server in the background with the help of screen.
As long as you are connected (attached) to the screen session, you can do anything here like in a normal terminal session. If you want to leave the screen session again, just press CTRL+a, followed by the key d (CTRL+a sends a signal to the screen program that the next key stroke is something screen has to handle. The d key says to screen than: detach!).
If you have problems connecting to your server, you should check if there is no firewall blocking the traffic. If there is any firewall doing so, you have to unlock the port 27015 (UDP) for your server. For a more further configuration of the server (settings like warm up, max player count, map rotation and so on) you should visit the following page. It contains a almost complete server.cfg with a lot of comments: server.cfg on csgodev For further fine tuning at the game modes you should read the official tutorial wikipedia page from Valve about this: CS:GO Server gamemodes I also want to provide my own server.cfg file here. It’s rather simple and just sets some basic features, like friendly fire and warm up time. You can see my server.cfg file here: server.cfg The server.cfg has to be stored in the directory cfg which is a subdirectory of the csgo_server directory, the directory which we had chosen while downloading the CS:GO server software.
Enough of the words. I wish you a good time in CS:GO and best wishes for you and your server 🙂
Image source: openvpn.net Did you ever wanted to automatically do something after you OpenVPN client has successful connected to your OpenVPN server? To do so you can just add 2 simple lines to your client OpenVPN file:
This 2 lines above are doing the following:
script-security 2: Allows the calling of built-in executables (ip, route, ifconfig, …) and user-defined scripts (see next line). A script-security of 1 would mean that only built-in executables are allowed to be called.
up postscript.sh: This line defines the script which should be started after the client successfully connected to the server. In this case the script is called postscript.sh. If you don’t define the total path to the script here, the script has to be in the same directory as the OpenVPN client configuration.
And that’s it. After you are connected to your OpenVPN Server the given script will be fired up. Don’t forget to make the script executable for course. For e.g. I use this to create a route on specific clients after they connected to the OpenVPN server. Of course you can do whatever you want inside the script.
For some weeks ago, I decided to use Ansible as my central configuration tool of choice. The following text should give you a short intro in how to deploy files with Ansible.
What exactly is Ansible?
Now, what exactly is Ansible? Ansible is an auto configuration tool, which helps you to keep your configuration files central managed. You will benefit from easier configuration and you will save a lot of time. For example, if you have 3 DNS servers and you want to ensure that all this systems have the same db and configuration files used, you could use either a network storage (which is obviously something over the top here) or keep them central and push them to all DNS servers. And Ansible is exactly doing that. It pushes your configuration files on given hosts. Another really pro for Ansible is, that it uses SSH to do so. This means that you don’t have to install a service to get your machines configured. Ansible is agent-less.
How to install
For almost every distribution out there in the wild, Ansible is available in the system repositories. For Ubuntu / Debian you can easily do:
sudo apt-get install ansible
as well as for openSUSE you can just do:
sudo zypper install ansible
After this, you can find the standard configuration under /etc/ansible.
Make SSH ready for Ansible
Every host which will be managed via Ansible needs to have a Public Key and a user which is allowed to use this Public Key to connect to the Host. For my personal purposes I created a user which is allowed to change the files which are coming from Ansible. This is of course optional. You could also do this with the user root even if that means a little bit more of a security risk. Anyway, you have to generate a Public Key which is done with the following command for the user ant:
ant@ansible:~$ ssh-keygen -t rsa -b 4096
For our scenario, you shouldn’t set a password for the key. The other questions can be confirmed with pressing ENTER without any changes. After this your SSH Key is ready and you can push them to your Host which will be configured with Ansible later. After the following command is issued, the user ant on your Ansible system will be able to login as user ant on the system target without entering a password. As described above, you could also do this with the user root here:
Now you should be able to login via ssh as the user ant on the system target without entering a password.
Groups and Hosts
Now that you have the target System fed with an Public Key, you are able to make the target System known in Ansible. The Ansible configuration files are located at /etc/ansible. First of all you should add the target system in the /etc/ansible/hosts file:
Let me explain this file a little bit. You can enter a hostname per line in this file. Ansible then knows them and will deploy the given files. To make the configuration easier, you can use groups. A definition of a group start with [ and ends with ]. So in this case the host target.local.dom would be in the group testsystems. You can put one host into multiple groups.
The host is now known for Ansible. As next we need to define the files which will be pushed and where their going to be deployed at the root filesystem of the target host. For this, Ansible is using so called Playbooks. As its name implies, the Playbook is a collection of things which has to be done on the target system. You can do almost everything here which you also would be able to do by hand in the console. There a plenty of modules which can be used for e.g. Update your system, set file permission, and so on. And even if there is no module available which fits your needs, you can always use the bash module and write down what the system should do by yourself. A complete list of the modules and how to use them can be found at the official documentation. In this example we will push files to the target system. So we have to define this in the Playbook. You can either use the copy or the synchronize function within the file module to push the wanted files to the target. The following example will use the synchronize function:
So what does this Playbook do now? Let me explain this file step by step:
hosts: Here we insert the group(s) which has been declared in the /etc/ansible/hosts file. You can name here single hosts as well as groups. It’s always recommended to use groups here.
vars: In vars we can declare variables which are used within this Playbook configuration. There is actually one variable defined which is called files. This variable is used later in the tasks section.
gather_facts: This is true or false. The standard is true. gather_facts is collecting informations about your system which can be used within the modules. Here it is disabled because we know that this Playbook will running well with the settings we give Ansible.
become: In earlier versions of Ansible this was called sudo. Become decides wether this Playbook needs root /sudo privileges to run, or not. The way how the system will become the root is defined in the central ansible.cfg. If set to true, you have to ensure that the „become user“, is available on the target system and has sudo permissions.
tasks: In tasks we define what to do on the target system. In this case we have one task, which is named „copy files“. It uses synchronize which is provided by the file module. The source path is the path which is defined in the variable files at the beginning of the Playbook-file. The Destination is the absolute path on the target system. In this case „/opt“. At the end, we use a notifier. This notifier is calling „restart ssh“ if a file has really changed on the target system. „restart ssh“ is written down in the „handlers.yml“ file. This file has to be in the same directory as this Playbook.
This is a really short and easy example of the capabilitys of Ansible. As I said earlier, you can do a lot of more stuff. For this you should consider to read the official documentation. You can now save the file where ever you want. I recommend a place like /etc/ansible/conf.d. The filename ending should be .yml. So for e.g. we could save the file „testservers.yml“ under /etc/ansible/conf.d.
The handlers.yml file
As mentioned before, the handlers.yml file is just an addition to your existing Playbook. In the handlers file you can write down commands which can be reused a lot of more times. For example the „restart ssh“ command, which has been called in our Playbook, can be also needed by other upcoming hosts. To prevent for writing down the same commands again and again, we use an external extra file, which holds all the reusable commands. This file is here called handlers.yml and has to be stored in the same directory as your Playbooks. An example handlers file looks like this:
So as you can see, we use the module service to restart the services ssh and bind. The services are restarted on the target system, when they get called in a Playbook. In our Playbook-example above, the „restart ssh“ command is triggered after copying files.
Testing our new configuration
We have a valid hosts and Playbook file and our target system has the needed Public Key. So we should be ready to go. To start or „call“ a Playbook you have to issue the following command on your command line:
NOTE: Don’t forget, that you have to issue the command on your Ansible system, with the user which has the Public Key stored on the target system. Now your Ansible server system should start pushing the data to the target system. A output like this should be shown to you:
This means the files are successfully copied and the ssh service was restarted. This means your first Ansible Playbook is running fine without issues. Now you can go on in adding more tasks. Don’t for get the official documentation to do so 🙂