Skip to main content

Posts

Showing posts from August, 2017

iSCSI Server and client in CentOS 7

iSCSI (internet Small Computer System Interface) is common way to export storage to a client in enterprise environments (e.g. Clustering with DRBD). In this example, I'll show how to install the iscsi-server and map the exportet LUN to the client. I'm assuming you have a clean and updated version of CentOS 7.3 installed both on client the client and the server. My server's ip: 172.31.10.34 My client's ip: 172.31.10.35 We'll start by configuring the server. First we have to install the package 'targetcli'. This utility is used for all the configuration done. [archy@storage01 ~]$ sudo yum -y install targetcli Enable the service to start on boot and start it now. [archy@storage01 ~]$ sudo systemctl enable target.service && sudo systemctl start target.service Start the configuration by running [archy@storage01 ~]$ sudo targetcli Before configuring the iSCSI-Target I want to mention that there are two options to allocate the stor

Getting started with Puppet

What is Puppet? Puppet is a config management tool that helps automating, provisioning and mange the infrastructure using the puppet agent to connect to the server (master). The Files used by puppet to configure are saved in manifests. What you will need is fully configured private DNS for your infrastructure providing forward and reverse zones. Otherwise you will have to resolv all names using entries in /etc/hosts which gets very hard to manage really fast. You will also need to have port 8140/tcp open in your server's firewall. In my case, I'll be using the hostnames puppetmaster.archyslife.lan - 172.31.10.40 and client01.archyslife.lan - 172.31.10.50 . Important: There needs to be a dns-record (A) named puppet.yourdomain.tld which points to your master server. If you are using FreeIPA and the integrated DNS, you can simply run: [archy@ipa01 ~]$ ipa dnsrecord-add archyslife.lan puppet --a-ip-address=172.31.10.40 With that said, let's get started. First we

Windows Clients are not registering to the domain's WSUS

Sometimes there is a problem with Windows not reporting to the WSUS-Service. This is a quick fix that I found working. First start a administrative powershell and stop the Update-Service and the BITS-Service on the Client PS C:\> net stop bits PS C:\> net stop wuauserv Now have a look at the corresponding registry object Get-ItemProperty HKLM:\Software\Policies\Microsoft\Windows\WindowsUpdate In my case, the entries "WUServer" and "WUStatusServer" were set to update.microsoft.com. We can fix that by running PS C:\> Set-ItemProperty HKLM:\Software\Policies\Microsoft\Windows\WindowsUpdate -Name "WUServer" -Value "http://wsus.domain.tld:8530" PS C:\> Set-ItemProperty HKLM:\Software\Policies\Microsoft\Windows\WindowsUpdate -Name "WUStatusServer" -Value "http://wsus.domain.tld:8530" To check if the keys are set, run PS C:\> Get-ItemProperty HKLM:\Software\Policies\Microsoft\Windows\WindowsU

Migrating Spacewalk to an external Postgresql-DB

It's quite easy to migrate spacewalk to run off a external db-instance. Here I will show how to migrate the embedded db to an external server. The requirements: spacewalk-utils  and  spacewalk-dobby  must be installed on the spacewalk-server an external postgresql-server allowing connections from the spacewalk using your user and db Same version of the database on both servers (9.2) Let's get started First we need to stop all Spacewalk-services. Do that by running the following command: [archy@spacewalk ~]$ sudo spacewalk-service stop and start the db-service from spacewalk [archy@spacewalk ~]$ sudo db-control start Next we will make a backup of our currently running database. My recommendation is also to back it up and store it on a nother server regularly. [archy@spacewalk ~]$ sudo spacewalk-dump-schema --to=postgresql > spacewalk_migration_backup.sql Now we can stop the internal database [archy@spacewalk ~]$ sudo db-control stop Now we w

Don't disable or set SELinux to permissive!

It's a bit offtopic but still worth mentioning it. I recently stumbled upon a reddit post that, in my opinion, perfectly describes why SELinux should not be disabled or set to permissive in a production enviroment! By default it is configured quite secure and can prevent further 'damage'. If you need to add or rewrite policies and permissions, the manual is a good source of input. Just my 2 cents. Feel free to comment and / or suggest a topic.

Creating a pgpool-II based PostgreSQL Cluster

This time I'm going to do a small and quick walkthrough for a postgresql cluster install. I assume you have a clean install of CentOS 7.3 with all updates. The configuration itself is surprisingly simple. The enviroment I'm working with is: Node1: Hostname: pgsql01.archyslife.lan IP: 172.31.10.31 Member of IPA-Domain Selinux: enforcing Node2: Hostname: pgsql02.archyslife.lan IP: 172.31.10.32 Member of IPA-Domain Selinux: enforcing Cluster: Main Node: pgsql01.archyslife.lan Replica: pgsql02.archyslife.lan Virtual IP: 172.31.10.33 for the sake completeness I'll be adding a A-Record entry in the IPA-DNS. Let's start with the configuration of each node. First I will completely setup the Master without restarting the services, afterwards the replica will follow. Steps necessary for both nodes. Add the pgsql-repo to yum. [archy@pgsql01 ~]$ sudo yum -y install https://download.postgresql.org/pub/repos/yum/9.6/redhat/rhel-7-x86_64/pgdg-centos96-9.6