Picture of fiber connected switches and servers

Back to basics – Creating a centralised yum/dnf repository

Posted on Leave a commentPosted in CentOS 7, Fedora, Linux, RHEL 7, System Administration

So far in the “Back to Basics” series (if you can call it that), I’ve covered, setting up a local yum repository, creating a internal DNS server and creating a DHCP server.  Oh, and also then correcting the fact that I had missed the reverse DNS zone for my lab network!  Doh!!!  Now, none of this was by accident (accept the reverse zone mishap).

In an isolated network, access to installation media can be essential, DNS and DHCP a pretty much standard in all environments (there are some exceptions) and all are pretty much mandatory in order to get your network up and running.

The ultimate aim of this series is to end up with a server which can be used to build more servers and/or clients into the lab network that I am setting up.

Before we can reach this goal, there are a few outstanding things to tackle;

  • Making our local repository readable from within our network (this article)
  • Setting up a TFTP server and confirm it works
  • Enable PXE booting functionality via DHCPd
  • Customising our installs using Kickstart

The above will then provide a basic but functional method of deploying more servers and clients into the lab environment, across the network and removes the need for monkeying around with ISO images, USB sticks (if you were to do similar in a real network) and once tested removes the human errors that can be introduced when manually installing an OS multiple times.

So what do we need

  • Apache (a.k.a. httpd)

Installing Apache

Given that I set up a local yum repository based on the installation media, it couldn’t be simpler.

[toby@rhc-server ~]$ sudo yum install httpd
Loaded plugins: fastestmirror
baselocal                                                                                                            | 3.6 kB  00:00:00     
Loading mirror speeds from cached hostfile
Resolving Dependencies
--> Running transaction check
---> Package httpd.x86_64 0:2.4.6-17.el7.centos.1 will be installed
--> Processing Dependency: httpd-tools = 2.4.6-17.el7.centos.1 for package: httpd-2.4.6-17.el7.centos.1.x86_64
--> Processing Dependency: /etc/mime.types for package: httpd-2.4.6-17.el7.centos.1.x86_64
--> Processing Dependency: libaprutil-1.so.0()(64bit) for package: httpd-2.4.6-17.el7.centos.1.x86_64
--> Processing Dependency: libapr-1.so.0()(64bit) for package: httpd-2.4.6-17.el7.centos.1.x86_64
--> Running transaction check
---> Package apr.x86_64 0:1.4.8-3.el7 will be installed
---> Package apr-util.x86_64 0:1.5.2-6.el7 will be installed
---> Package httpd-tools.x86_64 0:2.4.6-17.el7.centos.1 will be installed
---> Package mailcap.noarch 0:2.1.41-2.el7 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

============================================================================================================================================
 Package                         Arch                       Version                                     Repository                     Size
============================================================================================================================================
Installing:
 httpd                           x86_64                     2.4.6-17.el7.centos.1                       baselocal                     2.7 M
Installing for dependencies:
 apr                             x86_64                     1.4.8-3.el7                                 baselocal                     103 k
 apr-util                        x86_64                     1.5.2-6.el7                                 baselocal                      92 k
 httpd-tools                     x86_64                     2.4.6-17.el7.centos.1                       baselocal                      77 k
 mailcap                         noarch                     2.1.41-2.el7                                baselocal                      31 k

Transaction Summary
============================================================================================================================================
Install  1 Package (+4 Dependent packages)

Total download size: 3.0 M
Installed size: 10 M
Is this ok [y/d/N]: y
Downloading packages:
--------------------------------------------------------------------------------------------------------------------------------------------
Total                                                                                                        12 MB/s | 3.0 MB  00:00:00     
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : apr-1.4.8-3.el7.x86_64                                                                                                   1/5 
  Installing : apr-util-1.5.2-6.el7.x86_64                                                                                              2/5 
  Installing : httpd-tools-2.4.6-17.el7.centos.1.x86_64                                                                                 3/5 
  Installing : mailcap-2.1.41-2.el7.noarch                                                                                              4/5 
  Installing : httpd-2.4.6-17.el7.centos.1.x86_64                                                                                       5/5 
  Verifying  : mailcap-2.1.41-2.el7.noarch                                                                                              1/5 
  Verifying  : httpd-2.4.6-17.el7.centos.1.x86_64                                                                                       2/5 
  Verifying  : apr-util-1.5.2-6.el7.x86_64                                                                                              3/5 
  Verifying  : apr-1.4.8-3.el7.x86_64                                                                                                   4/5 
  Verifying  : httpd-tools-2.4.6-17.el7.centos.1.x86_64                                                                                 5/5 

Installed:
  httpd.x86_64 0:2.4.6-17.el7.centos.1                                                                                                      

Dependency Installed:
  apr.x86_64 0:1.4.8-3.el7   apr-util.x86_64 0:1.5.2-6.el7   httpd-tools.x86_64 0:2.4.6-17.el7.centos.1   mailcap.noarch 0:2.1.41-2.el7  

Complete!

Confirm file and folder permissions

[toby@rhc-server ~]$ ll -Z /software/
drwxr-xr-x. root root unconfined_u:object_r:default_t:s0 centos7

One thing to consider here is SELinux.

Before you run for the hills screaming, just take a deep breath and embrace something that by default will make your server more secure, yes it does have a bit of a learning curve but doesn’t everything?

I’m a believer in using the tools available to ensure I end up with a secure and stable environment.  SELinux is one of those things which for many years I avoided like the plague but to be honest, that was due to me not having had the time to properly understand what it does and how it does it.

After spending some time tinkering with it, it didn’t seem half as scary.  For sure, it complicates things a little when you come to troubleshoot permission issues, but then everything is more contained.

Lets make sure that the directory containing the installation media, which is in a none standard location (as far as Apache is concerned), has the correct SELinux permissions assigned to the folder structure.  The easiest way is to copy the existing SELinux contexts from the /var/www/html and here is the command to do that;

[root@rhc-server ~]# cd /var/www/
[root@rhc-server www]# ll -Z
drwxr-xr-x. root root system_u:object_r:httpd_sys_script_exec_t:s0 cgi-bin
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 html
[root@rhc-server www]# chcon -R --reference=/var/www/html/ /software/centos7
[root@rhc-server www]# ll -Z /software/
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 centos7

As you can see we now have the right context associated with the centos7 directory, now we need to make sure the httpd.conf file is updated to present the centos7 directory and it’s contents to the outside world.

Rather than modifying the httpd.conf file itself it is recommended that you create your own .conf files in /etc/httpd/conf.d/ and these will be loaded after the initial httpd.conf file.  I created a single test files as follows;

[toby@rhc-server ~]$ cat /etc/httpd/conf.d/software.conf
Alias "/centos7" "/software/centos7"

<Directory /software/centos7>
Options +Indexes

Order allow,deny
Allow from all
Require all granted
</Directory>
Screenshot showing successful directory listing from client machine of centos7 media
Screenshot showing successful directory listing from client machine of centos7 media

The Alias allows you to point to a directory which is outside of Apaches’ DocumentRoot, (typically set to /var/www/html).  The Directory block, contains two things of note.  First, for testing I have added the “Options +Indexes” so that when I try to connect from a web browser on my client machine, I can confirm that I can see the contents of the repository directory.  The second chunk of config, starting “Order all,deny…” is there so that Apache will allow connections to this none standard location.

One thing I did have to do, that I haven’t stated above is allow HTTP connections through the firewall.

This was accomplished by way of a simple one liner;

[toby@rhc-server ~]$ sudo firewall-cmd --zone=public --add-service=http

Note.  To make this new firewall rule permanent you need to use the “–permanent” firewall-cmd option on the command line.  I added this afterwards once I was happy that everything was working.

Configuring a yum .repo file to access the centralised software repository

This is very similar in the steps taken when I setup the local yum repository.  The only difference this time will be that I’ll give it a more meaningful name and the file location will be a http:// address rather that a file:///.

So here is what I have put together;

[root@rhc-client yum.repos.d]# cat CentOS-lab-Media.repo 
[th_lab_server]
baseurl=http://rhc-server.lab.tobyheywood.com/centos7/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

And then, as the saying goes, the proof is in the pudding;

[root@rhc-client yum.repos.d]# yum repolist
Loaded plugins: fastestmirror, langpacks
Repository 'th_lab_server' is missing name in configuration, using id
th_lab_server                                                                                                        | 3.6 kB  00:00:00     
(1/2): th_lab_server/group_gz                                                                                        | 157 kB  00:00:00     
(2/2): th_lab_server/primary_db                                                                                      | 4.9 MB  00:00:00     
Loading mirror speeds from cached hostfile
repo id                                                            repo name                                                          status
th_lab_server                                                      th_lab_server                                                      8,465
repolist: 8,465

Oops, now it would appear I haven’t added a name parameter in the dot repo file.  Let me correct that…

[root@rhc-client yum.repos.d]# cat CentOS-lab-Media.repo
[th_lab_server]
name="CentOS7 Media on rhc-server.lab.tobyheywood.com"
baseurl=http://rhc-server.lab.tobyheywood.com/centos7/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

And now if I run the command “yum repolist” again, it should return the list of enabled repositories without complaining, oh and the repo name column will also show my desired name for my network enabled repository ( a shorter name may be better);

[root@rhc-client yum.repos.d]# yum repolist
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
repo id                                          repo name                                                              status
th_lab_server                                    "CentOS7 Media on rhc-server.lab.tobyheywood.com"             8,465
repolist: 8,465

And there we have it a working centralised repository, if you don’t have access to Red Hat Satellite server or if you don’t want to install the open source version Spacewalk.

I guess the final test, would be to install a couple of packages;

[root@rhc-client yum.repos.d]# yum install iostat
Loaded plugins: fastestmirror, langpacks
th_lab_server                                                                                                        | 3.6 kB  00:00:00
Loading mirror speeds from cached hostfile
No package iostat available.
Error: Nothing to do
[root@rhc-client yum.repos.d]# yum whatprovides iostat
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
th_lab_server/filelists_db                                                                                           | 5.8 MB  00:00:00
sysstat-10.1.5-4.el7.x86_64 : Collection of performance monitoring tools for Linux
Repo        : th_lab_server
Matched from:
Filename    : /usr/bin/iostat

sysstat-10.1.5-4.el7.x86_64 : Collection of performance monitoring tools for Linux
Repo        : @anaconda
Matched from:
Filename    : /usr/bin/iostat

[root@rhc-client yum.repos.d]# yum install sysstat -y
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
Package sysstat-10.1.5-4.el7.x86_64 already installed and latest version
Nothing to do

Ah, I guess a demo is never meant to go really smoothly, but this is probably better as it demonstrates some awesome functionality that yum has.

Line 3, shows that it has found my networked repo, line 5 shows that there is no such package in the repo, line 7 highlights a way to find the right package for the command you want to run, lines 10 through 14 show conclusively that it has connected across the network to the repo, and has found a suitable package called sysstat. In line 21, I’m trying to install the package only to be told in line 24 that it’s already installed.

The really keen eyed of you may have also spotted the @anaconda repo, this should have rung an alarm bell in my head to say, hey!  What are you doing?  Its already installed!

Useful link – RPM DB Recovery

Posted on Leave a commentPosted in CentOS 7, Fedora, Linux, RHEL 6, RHEL 7, RPM, System Administration

Every now and then, we find ourselves in a bit of a predicament.  In this instance whilst performing an upgrade on a server, things just weren’t going well and it appeared we had some corruption in the RPM database on one of our servers.

We were seeing segmentation faults when trying to use “rpm”.

The following page on the rpm.org website proved very useful, in getting things back up and running swiftly;

http://www.rpm.org/wiki/Docs/RpmRecovery

DHCPD and the mysterious “host unknown”

Posted on Leave a commentPosted in CentOS 7, DHCP, DNS, Fedora, Linux, RHEL 7

For those of you following my “back to basics” series, in my last post setting up a dhcp server, I finished up with an error that flummoxed me initially.

Feb 22 22:13:36 rhc-server dhcpd[2682]: ns.lab.tobyheywood.com: host unknown.
Feb 22 22:13:36 rhc-server dhcpd[2682]: rtr.lab.tobyheywood.com: host unknown.

I had tried;

  • pinging the supposedly unknown hosts
    • both locally on the server which has the named daemon on it
    • remotely from the client that had just been assigned an IP address from my newly installed dhcp server
  • used tools such as dig to confirm the zone looked fine
  • double checked the dhcpd.conf file
  • nothing stood out as being odd
  • So, as it was late, I went to bed with the determination that I would research and fix the issue before me!

So I started reading through the dhcpd.conf man page (an online version though no guarantee it’s the latest version, can be found here http://linux.die.net/man/5/dhcpd.conf).

After scanning through the first few sections, I began reading about the steps required to setup Dynamic DNS Updates (ddns) and spied the recommendations regarding securing the dynamic DNS configuration. And something suddenly occurred to me… I hadn’t created a reverse lookup zone!!!

To the bat cave!

Now before I begin, there are two things I should mention;

  1. It’s good to reboot
  2. After rebooting my virtual machines it fixed my issue, but I suspect something had not refreshed as both the DNS and DHCP servers were created in the same evening.  I had also made modifications to my NIC setup to reflect the fact that I now had a local DNS server.
  3. Bonus material, I shall continue with the reverse zone creation steps.

Just to double check that I am setting up my reverse zone, I also consulted the current documentation for Red Hat Enterprise Linux 7 (essential CentOS 7) https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-BIND.html#sec-bind-zone.  I guess now is a good time to mention the fact that Red Hat does have some awesome documentation and you really should take the time to read all of it (which I have), as quite often not only do you find out the bits of information you were looking for but also you will find some interesting shortcuts and new ways of doing things.

Anyway…

Creating a reverse zone

So my reverse zone file looks like this

[root@rhc-server data]# cat lab.tobyheywood.com.rr.zone
$ORIGIN 20.168.192.in-addr.arpa.
$TTL 1d
@    IN    SOA    ns.lab.tobyheywood.com.    hostmaster.lab.tobyheywood.com. (
2016022400    ; Serial
6h        ; Refresh
1h        ; Retry
2d        ; Expire
1d )        ; Minimum TTL
;
@    IN    NS    ns.lab.tobyheywood.com.
;
1    IN    PTR    rhc-server.lab.tobyheywood.com.

Annoyingly the formatting seems to ignore tabs and multiple spacing where I put the code snippets on my website but I can assure you it is all neatly indented to ensure easy reading.

And I also added the following into the /etc/named.conf file;

[root@rhc-server data]# cat /etc/named.conf
options {
listen-on port 53 { 192.168.20.1; };
//listen-on-v6 port 53 { ::1; };
directory     "/var/named";
dump-file     "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
allow-query     { any; };

dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;

/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key";

managed-keys-directory "/var/named/dynamic";

pid-file "/run/named/named.pid";
session-keyfile "/run/named/session.key";
};

logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};

zone "." IN {
type hint;
file "named.ca";
};

zone "lab.tobyheywood.com" IN {
type master;
file "data/lab.tobyheywood.com";
allow-update { none; };
};

zone "20.168.192.in-addr.arpa" IN {
type master;
file "data/lab.tobyheywood.com.rr.zone";
allow-update { none; };
};

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";

Now I spotted that “recursion yes” had not be commented whilst I was adding the new zone “20.168.192.in-addr.arpa”.  This is unwanted as I do not want the server to be a caching DNS server, I’m only interested at this time in it providing my internal host details and nothing more.

[root@rhc-server data]# dig -x 192.168.20.1

; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> -x 192.168.20.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45831
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;1.20.168.192.in-addr.arpa.    IN    PTR

;; ANSWER SECTION:
1.20.168.192.in-addr.arpa. 86400 IN    PTR    rhc-server.lab.tobyheywood.com.

;; AUTHORITY SECTION:
20.168.192.in-addr.arpa. 86400    IN    NS    ns.lab.tobyheywood.com.

;; ADDITIONAL SECTION:
ns.lab.tobyheywood.com.    86400    IN    A    192.168.20.1

;; Query time: 0 msec
;; SERVER: 192.168.20.1#53(192.168.20.1)
;; WHEN: Wed Feb 24 23:20:47 GMT 2016
;; MSG SIZE  rcvd: 131

And there we have it, a reverse DNS zone has been born!  Yay!

Back to basics – Setting a DHCP server

Posted on Leave a commentPosted in CentOS 7, DHCP, Linux, Networking, System Administration

Following on from other posts in the “back to basics” series; Local yum repository and setting up an internal DNS server. Here is the next step in the process of building a infrastructure services server.

So we have DNS in place and working.  Now lets make sure that none of the client machines in the lab have to be configured with an IPv4 address manually.

First things first, lets get dhcp installed;

[root@rhc-server etc]# yum install dhcp -y

Before I look to configure DHCP for my needs, lets just have a quick look at the example configuration file.  This is good for a number of reasons, sometimes you will see certain options being used which you would not have used if it weren’t for having seen them in an example.

[root@rhc-server etc]# cat /usr/share/doc/dhcp*/dhcpd.conf.example
# dhcpd.conf
#
# Sample configuration file for ISC dhcpd
#

# option definitions common to all supported networks...
option domain-name "example.org";
option domain-name-servers ns1.example.org, ns2.example.org;

default-lease-time 600;
max-lease-time 7200;

# Use this to enble / disable dynamic dns updates globally.
#ddns-update-style none;

# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
#authoritative;

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;

# No service will be given on this subnet, but declaring it helps the
# DHCP server to understand the network topology.

subnet 10.152.187.0 netmask 255.255.255.0 {
}

# This is a very basic subnet declaration.

subnet 10.254.239.0 netmask 255.255.255.224 {
range 10.254.239.10 10.254.239.20;
option routers rtr-239-0-1.example.org, rtr-239-0-2.example.org;
}

# This declaration allows BOOTP clients to get dynamic addresses,
# which we don't really recommend.

subnet 10.254.239.32 netmask 255.255.255.224 {
range dynamic-bootp 10.254.239.40 10.254.239.60;
option broadcast-address 10.254.239.31;
option routers rtr-239-32-1.example.org;
}

# A slightly different configuration for an internal subnet.
subnet 10.5.5.0 netmask 255.255.255.224 {
range 10.5.5.26 10.5.5.30;
option domain-name-servers ns1.internal.example.org;
option domain-name "internal.example.org";
option routers 10.5.5.1;
option broadcast-address 10.5.5.31;
default-lease-time 600;
max-lease-time 7200;
}

# Hosts which require special configuration options can be listed in
# host statements.&nbsp;&nbsp; If no address is specified, the address will be
# allocated dynamically (if possible), but the host-specific information
# will still come from the host declaration.

host passacaglia {
hardware ethernet 0:0:c0:5d:bd:95;
filename "vmunix.passacaglia";
server-name "toccata.fugue.com";
}

# Fixed IP addresses can also be specified for hosts.&nbsp;&nbsp; These addresses
# should not also be listed as being available for dynamic assignment.
# Hosts for which fixed IP addresses have been specified can boot using
# BOOTP or DHCP.&nbsp;&nbsp; Hosts for which no fixed address is specified can only
# be booted with DHCP, unless there is an address range on the subnet
# to which a BOOTP client is connected which has the dynamic-bootp flag
# set.
host fantasia {
hardware ethernet 08:00:07:26:c0:a5;
fixed-address fantasia.fugue.com;
}

# You can declare a class of clients and then do address allocation
# based on that.&nbsp;&nbsp; The example below shows a case where all clients
# in a certain class get addresses on the 10.17.224/24 subnet, and all
# other clients get addresses on the 10.0.29/24 subnet.

class "foo" {
match if substring (option vendor-class-identifier, 0, 4) = "SUNW";
}

shared-network 224-29 {
subnet 10.17.224.0 netmask 255.255.255.0 {
option routers rtr-224.example.org;
}
subnet 10.0.29.0 netmask 255.255.255.0 {
option routers rtr-29.example.org;
}
pool {
allow members of "foo";
range 10.17.224.10 10.17.224.250;
}
pool {
deny members of "foo";
range 10.0.29.10 10.0.29.230;
}
}

As we can see from the above, the examples have provided us with pretty much everything we need to know and more to get things up and running.  Below is the configuration file that I created;

[root@rhc-server dhcp]# cat dhcpd.conf
#
#&nbsp; lab.tobyheywood.com dhcp daemon configuration file
#
#&nbsp; 2016-02-22 - Initial creation
#

# Define which IP to listen on.&nbsp; NOTE. daemon can only listen to one
# IP at a time if defined.
local-address 192.168.20.1;

# option definitions common to all supported networks...
option domain-name "lab.tobyheywood.com";
option domain-name-servers ns.lab.tobyheywood.com;

default-lease-time 600;
max-lease-time 7200;

# Use this to enble / disable dynamic dns updates globally.
#ddns-update-style interim;

# This is the authoritative DHCP server.
authoritative;

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;

# My management network on a separate interface
# Included in configuration otherwise I get errors in journalctl
# **** NOT IN USE ****
subnet 192.168.122.0 netmask 255.255.255.0 {
}

# The lab network
subnet 192.168.20.0 netmask 255.255.255.128 {
range 192.168.20.50 192.168.20.99;
option routers rtr.lab.tobyheywood.com;
}

Hopefully the comments above are sufficient to give you a good idea of what each bit is therefore and what it does.

Now lets start the dhcpd daemon and check everything is working as it should.

[root@rhc-server dhcp]# systemctl enable dhcpd
[root@rhc-server dhcp]# systemctl start dhcpd
[root@rhc-server dhcp]# systemctl list-units | grep named
named.service        loaded active running     Berkeley Internet Name Domain (DNS)
[root@rhc-server dhcp]# systemctl list-units | grep -e dhcpd
dhcpd.service        loaded active running     DHCPv4 Server Daemonctl

And a quick review of the logs shows we are cooking with gas!

Feb 22 22:11:13 rhc-server systemd[1]: Starting DHCPv4 Server Daemon...
Feb 22 22:11:13 rhc-server systemd[1]: Started DHCPv4 Server Daemon.
Feb 22 22:11:13 rhc-server dhcpd[3145]: Internet Systems Consortium DHCP Server 4.2.5
Feb 22 22:11:13 rhc-server dhcpd[3145]: Copyright 2004-2013 Internet Systems Consortium.
Feb 22 22:11:13 rhc-server dhcpd[3145]: All rights reserved.
Feb 22 22:11:13 rhc-server dhcpd[3145]: For info, please visit https://www.isc.org/software/dhcp/
Feb 22 22:11:13 rhc-server dhcpd[3145]: Not searching LDAP since ldap-server, ldap-port and ldap-base-dn were not specified in the...ig file
Feb 22 22:11:13 rhc-server dhcpd[3145]: Internet Systems Consortium DHCP Server 4.2.5
Feb 22 22:11:13 rhc-server dhcpd[3145]: Copyright 2004-2013 Internet Systems Consortium.
Feb 22 22:11:13 rhc-server dhcpd[3145]: All rights reserved.
Feb 22 22:11:13 rhc-server dhcpd[3145]: For info, please visit https://www.isc.org/software/dhcp/
Feb 22 22:11:13 rhc-server dhcpd[3145]: Wrote 1 leases to leases file.
Feb 22 22:11:13 rhc-server dhcpd[3145]: Listening on LPF/ens8/52:54:00:ca:b3:a6/192.168.20.0/25
Feb 22 22:11:13 rhc-server dhcpd[3145]: Sending on&nbsp;&nbsp; LPF/ens8/52:54:00:ca:b3:a6/192.168.20.0/25
Feb 22 22:11:13 rhc-server dhcpd[3145]: Listening on LPF/ens3/52:54:00:2b:da:2b/192.168.122.0/24
Feb 22 22:11:13 rhc-server dhcpd[3145]: Sending on&nbsp;&nbsp; LPF/ens3/52:54:00:2b:da:2b/192.168.122.0/24
Feb 22 22:11:13 rhc-server dhcpd[3145]: Sending on&nbsp;&nbsp; Socket/fallback/fallback-net
Feb 22 22:13:35 rhc-server dhcpd[3145]: DHCPDISCOVER from 52:54:00:a6:a4:fa via ens8
Feb 22 22:13:35 rhc-server dhcpd[2682]: DHCPDISCOVER from 52:54:00:a6:a4:fa via ens8
Feb 22 22:13:36 rhc-server dhcpd[3145]: DHCPOFFER on 192.168.20.50 to 52:54:00:a6:a4:fa (rhc-client) via ens8
Feb 22 22:13:36 rhc-server dhcpd[2682]: ns.lab.tobyheywood.com: host unknown.
Feb 22 22:13:36 rhc-server dhcpd[2682]: rtr.lab.tobyheywood.com: host unknown.
Feb 22 22:13:36 rhc-server dhcpd[2682]: DHCPOFFER on 192.168.20.50 to 52:54:00:a6:a4:fa (rhc-client) via ens8
Feb 22 22:13:37 rhc-server dhcpd[3145]: DHCPREQUEST for 192.168.20.50 (192.168.20.1) from 52:54:00:a6:a4:fa (rhc-client) via ens8
Feb 22 22:13:37 rhc-server dhcpd[3145]: DHCPACK on 192.168.20.50 to 52:54:00:a6:a4:fa (rhc-client) via ens8
Feb 22 22:13:37 rhc-server dhcpd[2682]: DHCPREQUEST for 192.168.20.50 (192.168.20.1) from 52:54:00:a6:a4:fa (rhc-client) via ens8
Feb 22 22:13:37 rhc-server dhcpd[2682]: DHCPACK on 192.168.20.50 to 52:54:00:a6:a4:fa (rhc-client) via ens8

So with the exception of the two “host unknown” errors we are looking good!  So that will do for now.

Time to go investigate the host unknown issue, ggrrrrrr!  Can I ping it? Yes I can!

Back to basics – Setting up a local (internal) DNS server

Posted on Leave a commentPosted in CentOS 7, DNS, Linux, RHEL 7, System Administration

Today’s “back to basics” post is all about setting up a local internal DNS server. Though there are a number of applications out there which will ease the process of setting up DNS and/or DHCP services, I am sticking with what would be used in the enterprise environment and also focusing on doing things manually.

Why manually?? Well, it has been a while since I’ve had to configure named from scratch and so it’s good to remind me how it all fits together. Plus, by knowing how the internals are working (as far as the configuration is concerned) it means if I run into problems, then I’m better placed to fix the issue sooner and with less searching.

So for DNS that would be (IMHO) BIND.  BIND has been around for a very long time and for those of you with an interest in it’s history, take a look at; BIND – Wikipedia.  In CentOS and RHEL you have two options the base BIND packages or an additional package which configures BIND to run in a chroot jail.

Because I am only setting this up for the purpose of a lab, I will not be making use of the chroot version (though in all honesty it doesn’t require much additional effort) and will stick
instead with the base package.  HOWEVER, IF you are going to use BIND on a server which has a public facing interface onto the big
, bad Internet, then without doubt, MAKE SURE YOU USE THE CHROOT package too.  There is no reason not to in my opinion!

Back to the lab installation


[root@rhc-server ~]# yum install bind -y
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
Resolving Dependencies
--> Running transaction check
---> Package bind.x86_64 32:9.9.4-14.el7 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

============================================================================================================================================
Package                     Arch                          Version                                   Repository                        Size
============================================================================================================================================
Installing:
bind                        x86_64                        32:9.9.4-14.el7                           baselocal                        1.8 M

Transaction Summary
============================================================================================================================================
Install  1 Package

Total download size: 1.8 M
Installed size: 4.3 M
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installing : 32:bind-9.9.4-14.el7.x86_64                                                                                              1/1
Verifying  : 32:bind-9.9.4-14.el7.x86_64                                                                                              1/1

Installed:
bind.x86_64 32:9.9.4-14.el7

Complete!

OK, so now we have it installed we need to create a zone file which will contain all of our required internal DNS zone information.  Zone files are stored in the /var/named/data directory (or if using chroot version of bind /var/named/chroot/var/named/data).  As you can see currently there are no zone files in this location;


[root@rhc-server data]# pwd
/var/named/data
[root@rhc-server data]# ls
[root@rhc-server data]#

For my internal DNS I’m going setting up a zone called “lab.tobyheywood.com” and the zone file looks more or less as follows;


[root@rhc-server data]# cat lab.tobyheywood.com
$TTL 1d
@        IN    SOA    ns.lab.tobyheywood.com.    hostmaster.lab.tobyheywood.com. (
2016022100    ; Serial
1h        ; Refresh
15m        ; Retry
10d        ; Expire (10 days should be enough in the lab)
1h )        ; Negative Cache
;
; Name Servers
IN    NS    ns.lab.tobyheywood.com.
;
; MX Records (Mail eXchange)
;
; CNAME (Canonical Name a.k.a. Aliases)
provision    IN    CNAME    ns.lab.tobyheywood.com.
;
; A Records (IPv4 addresses)
ns        IN    A    192.168.20.1
rhc-server    IN    A    192.168.20.1

;
; AAAA Records (IPv6 Records)
; - Not used yet but at a later stage in the lab

As you can probably spot, I am using the IPv4 address 192.168.20.1 as the primary IP address for my server.

The next step is to updated the /etc/named.conf file so that it is listening on the right ip address and also to define the zone I have just created.

//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//

options {
listen-on port 53 { 192.168.20.1; };
//listen-on-v6 port 53 { ::1; };
directory     "/var/named";
dump-file     "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
allow-query     { any; };

dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;

/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key";

managed-keys-directory "/var/named/dynamic";

pid-file "/run/named/named.pid";
session-keyfile "/run/named/session.key";
};

logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};

zone "." IN {
type hint;
file "named.ca";
};

zone "lab.tobyheywood.com" IN {
type master;
file "data/lab.tobyheywood.com";
};

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";

To maintain a level of sanity, lets just do a couple of checks to make sure everything is, as it should be.


[root@rhc-server etc]# named-checkzone lab.tobyheywood.com /var/named/data/lab.tobyheywood.com
zone lab.tobyheywood.com/IN: loaded serial 2016022100
OK
[root@rhc-server etc]# named-checkconf
[root@rhc-server etc]# echo $?
0
[root@rhc-server etc]#

And now time to enable the service, start it and then test that I have got everything right.  Also as part of this step I have installed bind-utils so that I can confirm the zone is active by way of querying the name server.;


[root@rhc-server etc]# systemctl enable named
ln -s '/usr/lib/systemd/system/named.service' '/etc/systemd/system/multi-user.target.wants/named.service'
[root@rhc-server etc]# systemctl start named.service
[root@rhc-server etc]# yum install bind-utils -y
[root@rhc-server etc]# ping rhc-server.lab.tobyheywood.com -c 5
PING rhc-server.lab.tobyheywood.com (192.168.20.1) 56(84) bytes of data.
64 bytes from 192.168.20.1: icmp_seq=1 ttl=64 time=0.021 ms
64 bytes from 192.168.20.1: icmp_seq=2 ttl=64 time=0.093 ms
64 bytes from 192.168.20.1: icmp_seq=3 ttl=64 time=0.091 ms
64 bytes from 192.168.20.1: icmp_seq=4 ttl=64 time=0.053 ms
64 bytes from 192.168.20.1: icmp_seq=5 ttl=64 time=0.093 ms

--- rhc-server.lab.tobyheywood.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4002ms
rtt min/avg/max/mdev = 0.021/0.070/0.093/0.029 ms
[root@rhc-server etc]# dig ns.lab.tobyheywood.com

; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> ns.lab.tobyheywood.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56872
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ns.lab.tobyheywood.com.        IN    A

;; ANSWER SECTION:
ns.lab.tobyheywood.com.    86400    IN    A    192.168.20.1

;; AUTHORITY SECTION:
lab.tobyheywood.com.    86400    IN    NS    ns.lab.tobyheywood.com.

;; Query time: 0 msec
;; SERVER: 192.168.20.1#53(192.168.20.1)
;; WHEN: Sun Feb 21 18:50:48 GMT 2016
;; MSG SIZE  rcvd: 81

The only thing that I had done ahead of time was to make sure that my /etc/resolv.conf file was updated to reflect the correct search and nameserver parameters.  So all in all looking good.

Till next time.

UPDATE!!!!

Err, well.  That’s embarrassing!  So as part of the above post though it work, somethings will not.  More specifically, if you try to perform a reverse look up it will fail miserably.  So to complete the picture, you can see what I did with regards the reverse zone here.

Network bonding vs teaming in Linux

Posted on Leave a commentPosted in Fedora, Linux, RHEL 7

The terms bonding and teaming are quite often used interchangeably, especially when wearing both Linux and Microsoft hats.  And that term is further confused once you start wearing your network admin hat as well.

However, in the world of Linux (in my case Fedora/CentOS/RHEL) there are distinct differences between the terms.  One is the future of network interface collaboration, whilst the other is still very much capable, it lacks some of the features people may find useful going forward.

And to quote the Red Hat Enterprise Linux 7 Networking Guide;

“The combining or aggregating together of network links in order to provide a logical link with higher throughput, or to provide redundancy, is known by many names such as channel bonding, Ethernet bonding, port trunking, channel teaming, NIC teaming, link aggregation, and so on. This concept as originally implemented in the Linux kernel is widely referred to as bonding. The term Network Teaming has been chosen to refer to this new implementation of the concept. The existing bonding driver is unaffected, Network Teaming is offered as an alternative and does not replace bonding in Red Hat Enterprise Linux 7. ”

So why should you consider adopting teaming rather than the bonding method?

If you are looking for a complete comparison from the horses mouth, then may I suggest the; Red Hat Enterprise Linux Networking Guide: Comparison of Network Teaming to Bonding.

The key reasons why you might want to use teaming rather than bonding are;

  • Teaming has a small kernel module which implements fast handling of packets flowing through your teamed interfaces
  • support for IPv6 (NS/NA) link monitoring
  • Capable of working with D-Bus and Unix Domain Sockets (the default)
  • It provides an extensible and scale-able solution for your teaming requirements
  • load balancing for LACP support
  • It makes use of NetworkManager and its associates tools (the modern way) to manage your network connections

For me, I see teamd as ultimately the replacement for bonding in the coming years.  Especially given that you can make use of tools such as nmcli which means that automation and repeatable configuration becomes much simper as the cli tools remove a lot of the checking and verification steps you would ultimately want when developing your own scripts to do the same job in a more manual fashion.

Obviously, NetworkManager has been around for a while so standard configurations could be applied using the likes of nmcli, but for anything more involved (see above reasons why you might consider teamd) then it becomes a no-brainer!

Anyway, I would highly recommend reading the Red Hat Enterprise Linux 7 documentation, there are some amazing nuggets of information in there.

Enabling GNS3 to talk to it’s host and beyond

Posted on Leave a commentPosted in Fedora, GNS3, Linux, Networking, Networks, RHEL 7, System Administration

I’m currently working my way through a CCNA text book and reached a point where I need to be able perform some tasks which rely on connecting the virtual network environment inside of GNS3 to the host machine, for the purpose of connecting to a tftp service (just in case you were curious).

After a little googling it became apparent that this is indeed possible, though most of the guides focused on using GNS3 on a Windows machine. Where as I, am very much a Linux guy.

So as a reminder to myself but also as a helpful reference for others here is what I had to do on my Fedora 22 machine

The first way was using standard tools in Linux, the second I made sure I was able to create the same setup using Network Manager (again to make sure that I am utilising the latest tools for the job).

Standard method (from the command line)

$ sudo dnf install tunctl
$ tunctl -t tap0 -u toby
$ ifconfig tap0 10.0.1.10 netmask 255.255.255.0 up
$ firewall-cmd --zone=FedoraWorkstation --add-interface=tap0 --permanent

 

Using Network Manager (from the command line)

$ sudo ip tuntap add dev tap1 mode tap user toby
$ sudo ip addr add 10.0.0.10/255.255.255.0 dev tap1
$ sudo ip link set tap1 up
$ sudo firewall-cmd --zone=FedoraWorkstation --add-interface=tap1
$ sudo ip addr show tap1
11: tap1: <broadcast,multicast,up,lower_up> mtu 1500 qdisc fq_codel state UP group default qlen 500
link/ether 26:2b:e4:a0:54:ba brd ff:ff:ff:ff:ff:ff
inet 10.0.0.10/24 scope global tap1
valid_lft forever preferred_lft forever
inet6 fe80::242b:e4ff:fea0:54ba/64 scope link 
valid_lft forever preferred_lft forever

Configuring the interface on the Cisco router inside of GNS3

router1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
router1(config)#int f0/0
router1(config-if)#ip address 10.0.0.1 255.255.255.0
router1(config-if)#no shut
router1(config)
router1>write mem

The bit of config inside GNS3

I nearly forgot to write this section.  Doh!  Anyway, it’s lucky for everyone that I remember, so without any further padding… seriously, no more padding… the config in GNS3…

GNS3_Side_Panel
Select Cloud from the side panel in GNS3.

Next we need to configure the cloud… (hint.  right click the cloud and select configure).

GNS3_tap1_configuration_screen
Select TAP and then type in the name of the tap device created, in my case tap1.

The final step is to draw the virtual connection between the cloud and the router (making sure to map it to the correct interface).

At this point we should be in a happy place.

Proof that it works

# ping -c 5 10.0.0.10
PING 10.0.0.10 (10.0.0.10) 56(84) bytes of data.
64 bytes from 10.0.0.10: icmp_seq=1 ttl=64 time=0.103 ms
64 bytes from 10.0.0.10: icmp_seq=2 ttl=64 time=0.096 ms
64 bytes from 10.0.0.10: icmp_seq=3 ttl=64 time=0.050 ms
64 bytes from 10.0.0.10: icmp_seq=4 ttl=64 time=0.058 ms
64 bytes from 10.0.0.10: icmp_seq=5 ttl=64 time=0.103 ms

--- 10.0.0.10 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3999ms
rtt min/avg/max/mdev = 0.050/0.082/0.103/0.023 ms
# ping -c 5 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=1 ttl=255 time=9.16 ms
64 bytes from 10.0.0.1: icmp_seq=2 ttl=255 time=5.64 ms
64 bytes from 10.0.0.1: icmp_seq=3 ttl=255 time=11.2 ms
64 bytes from 10.0.0.1: icmp_seq=4 ttl=255 time=7.29 ms
64 bytes from 10.0.0.1: icmp_seq=5 ttl=255 time=2.98 ms

--- 10.0.0.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 2.980/7.266/11.253/2.847 ms

router1#ping 10.0.0.10

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.10, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 4/9/12 ms

I do believe that about covers.

Kernel Tuning: kernel.core_pattern

Posted on Leave a commentPosted in Kernel Tuning, Linux

There are two types of core dump which can take place on a linux based system.

  1. Application core dump
  2. Kernel core dump

kernel.core_pattern tunable relates to the former (application dump).  It is used to control where application core dumps are saved and also how they will be named.

Application core dumps can occur, for example, when there is a memory segmentation fault.

Here is an example of the kernel.core_pattern when set in the sysctl.conf file;

<i>kernel.core_pattern = /you/define/the/path/appcore-%e-%s-%u-%g-%p-%t

The formatting placeholders used above have the following definitions;

# appcore = generic reference to what is in the file
# %e = executable file name (without the path being prefixed
# %s = the number of the signal which caused the application to crash out and dump it's contents
# %u = the real ID which was running the dumped process
# %g = the real GID which was running the dumped process
# %p = the pid of the dumped process
# %t = the time of the dump

The following is stolen from the core(5) man page;

<pre>   <b>Naming of core dump files</b>
       By default, a core dump file is named <i>core</i>, but the
       <i>/proc/sys/kernel/core_pattern file (since Linux 2.6 and 2.4.21) can
       be set to define a template that is used to name core dump files.
       The template can contain % specifiers which are substituted by the
       following values when a core file is created:

           %%  a single % character
           %c  core file size soft resource limit of crashing process (since
               Linux 2.6.24)
           %d  dump mode—same as value returned by <a href="http://man7.org/linux/man-pages/man2/prctl.2.html">prctl(2)</a> <b>PR_GET_DUMPABLE</b>
               (since Linux 3.7)
           %e  executable filename (without path prefix)
           %E  pathname of executable, with slashes ('/') replaced by
               exclamation marks ('!') (since Linux 3.0).
           %g  (numeric) real GID of dumped process
           %h  hostname (same as <i>nodename</i> returned by <a href="http://man7.org/linux/man-pages/man2/uname.2.html">uname(2)</a>)
           %i  TID of thread that triggered core dump, as seen in the PID
               namespace in which the thread resides (since Linux 3.18)
           %I  TID of thread that triggered core dump, as seen in the
               initial PID namespace (since Linux 3.18)
           %p  PID of dumped process, as seen in the PID namespace in which
               the process resides
           %P  PID of dumped process, as seen in the initial PID namespace
               (since Linux 3.12)
           %s  number of signal causing dump
           %t  time of dump, expressed as seconds since the Epoch,
               1970-01-01 00:00:00 +0000 (UTC)
           %u  (numeric) real UID of dumped process

       A single % at the end of the template is dropped from the core
       filename, as is the combination of a % followed by any character
       other than those listed above.  All other characters in the template
       become a literal part of the core filename.  The template may include
       '/' characters, which are interpreted as delimiters for directory
       names.  The maximum size of the resulting core filename is 128 bytes
       (64 bytes in kernels before 2.6.19).  The default value in this file
       is "core".  For backward compatibility, if
       <i>/proc/sys/kernel/core_pattern</i> does not include "%p" and
       <i>/proc/sys/kernel/core_uses_pid</i> (see below) is nonzero, then .PID will
       be appended to the core filename.

       Since version 2.4, Linux has also provided a more primitive method of
       controlling the name of the core dump file.  If the
       <i>/proc/sys/kernel/core_uses_pid</i> file contains the value 0, then a core
       dump file is simply named <i>core</i>.  If this file contains a nonzero
       value, then the core dump file includes the process ID in a name of
       the form <i>core.PID</i>.

       Since Linux 3.6, if <i>/proc/sys/fs/suid_dumpable</i> is set to 2
       ("suidsafe"), the pattern must be either an absolute pathname
       (starting with a leading '/' character) or a pipe, as defined below.

GNS3 – Problems Compiling IOUYAP

Posted on Leave a commentPosted in C++, Fedora, Linux, Networks

Following the series of posts over recent months relating to the installation of GNS3; 1) Installing GNS3 on Fedora, CentOS and RHEL and 2) GNS3 Installation on Fedora 22 I have decided to put together a complete guide from start to finish chronicling my every step to ensure my GNS3 installation is correct and fully working.

It is at this point that I feel that I should not just share the normal story of “everything went fine… what problems?? I didn’t have a single issue installing the software!!!”  Well, for the most part I could have got away with a statement like that.  Unfortunately though when I reached the point of installing iouyap, things didn’t go quite as smoothly as one would hope.

As per my previous guides and the instructions that ship with iouyap (version 0.95) I ran the following;

$ bison --yacc -dv netmap_parse.y
$ flex netmap_scan.l
$ gcc -Wall -g *.c -o iouyap -liniparser -lpthread

I was the confronted with a wall of potential errors, and not knowing exactly what they meant, I thought it best to investigate…  The output from the last command line above was;

[toby@thebay iouyap-0.95]$ sudo gcc -Wall -g *.c -o iouyap -liniparser -lpthread
In file included from iouyap.c:49:0:
iouyap.c: In function ‘foreign_listener’:
iouyap.c:420:24: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘ssize_t {aka long int}’ [-Wformat=]
debug_log_fmt ("received %d bytes (sfd=%d)\n",
^
iouyap.h:103:28: note: in definition of macro ‘STMT’
#define STMT( code )  do { code } while (0)
^
iouyap.h:128:5: note: in expansion of macro ‘STMT’
STMT( log_prefix(); fprintf(stderr, fmt, ## __VA_ARGS__); )
^
iouyap.h:138:26: note: in expansion of macro ‘log_fmt’
STMT( if (DEBUG_LOG) log_fmt(fmt, ## __VA_ARGS__); )
^
iouyap.c:420:9: note: in expansion of macro ‘debug_log_fmt’
debug_log_fmt ("received %d bytes (sfd=%d)\n",
^
iouyap.c:458:28: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘ssize_t {aka long int}’ [-Wformat=]
log_fmt ("sendto() only sent %d of %d bytes!"
^
iouyap.h:103:28: note: in definition of macro ‘STMT’
#define STMT( code )  do { code } while (0)
^
iouyap.c:458:19: note: in expansion of macro ‘log_fmt’
log_fmt ("sendto() only sent %d of %d bytes!"
^
iouyap.c:458:28: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘ssize_t {aka long int}’ [-Wformat=]
log_fmt ("sendto() only sent %d of %d bytes!"
^
iouyap.h:103:28: note: in definition of macro ‘STMT’
#define STMT( code )  do { code } while (0)
^
iouyap.c:458:19: note: in expansion of macro ‘log_fmt’
log_fmt ("sendto() only sent %d of %d bytes!"
^
iouyap.c: In function ‘iou_listener’:
iouyap.c:536:24: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘ssize_t {aka long int}’ [-Wformat=]
debug_log_fmt ("received %d bytes for port %d (sfd=%d)\n",
^
iouyap.h:103:28: note: in definition of macro ‘STMT’
#define STMT( code )  do { code } while (0)
^
iouyap.h:128:5: note: in expansion of macro ‘STMT’
STMT( log_prefix(); fprintf(stderr, fmt, ## __VA_ARGS__); )
^
iouyap.h:138:26: note: in expansion of macro ‘log_fmt’
STMT( if (DEBUG_LOG) log_fmt(fmt, ## __VA_ARGS__); )
^
iouyap.c:536:9: note: in expansion of macro ‘debug_log_fmt’
debug_log_fmt ("received %d bytes for port %d (sfd=%d)\n",
^
iouyap.c:563:24: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘ssize_t {aka long int}’ [-Wformat=]
log_fmt ("write() only sent %d of %d bytes! (sfd=%d)\n",
^
iouyap.h:103:28: note: in definition of macro ‘STMT’
#define STMT( code )  do { code } while (0)
^
iouyap.c:563:15: note: in expansion of macro ‘log_fmt’
log_fmt ("write() only sent %d of %d bytes! (sfd=%d)\n",
^
iouyap.c:563:24: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘ssize_t {aka long int}’ [-Wformat=]
log_fmt ("write() only sent %d of %d bytes! (sfd=%d)\n",
^
iouyap.h:103:28: note: in definition of macro ‘STMT’
#define STMT( code )  do { code } while (0)
^
iouyap.c:563:15: note: in expansion of macro ‘log_fmt’
log_fmt ("write() only sent %d of %d bytes! (sfd=%d)\n",
^
In file included from netmap.c:34:0:
netmap.c: In function ‘dump_port_table’:
netmap.c:372:16: warning: format ‘%d’ expects argument of type ‘int’, but argument 6 has type ‘size_t {aka long unsigned int}’ [-Wformat=]
log_fmt ("%d:%d/%d talks to %d other node(s):\n", yap_appl_id,
^
iouyap.h:103:28: note: in definition of macro ‘STMT’
#define STMT( code )  do { code } while (0)
^
netmap.c:372:7: note: in expansion of macro ‘log_fmt’
log_fmt ("%d:%d/%d talks to %d other node(s):\n", yap_appl_id,
^

After some monkeying about, I reduced these errors to;

In file included from netmap.c:34:0:
netmap.c: In function ‘dump_port_table’:
netmap.c:372:16: warning: format ‘%d’ expects argument of type ‘int’, but argument 6 has type ‘size_t {aka long unsigned int}’ [-Wformat=]
log_fmt ("%d:%d/%d talks to %d other node(s):\n", yap_appl_id,
^
iouyap.h:103:28: note: in definition of macro ‘STMT’
#define STMT( code )  do { code } while (0)
^
netmap.c:372:7: note: in expansion of macro ‘log_fmt’
log_fmt ("%d:%d/%d talks to %d other node(s):\n", yap_appl_id,
^

the diff output is as follows;

diff iouyap.c ../../iouyap-0.95_original/iouyap-0.95/iouyap.c
383,384c383
<   /* ssize_t bytes_received, bytes_sent; */
<   int bytes_received, bytes_sent; --- >   ssize_t bytes_received, bytes_sent;
503,504c502
<   /* ssize_t bytes_received, bytes_sent; */
<   int bytes_received, bytes_sent; --- >   ssize_t bytes_received, bytes_sent;

Now I’m no C++ developer, not even close, and the last thing to resolve in netmap.c just didn’t make sense. So I paid the gns3 website a visit, and magically less than 24 hours after I had downloaded the 1.3.8 version there was a new release… 1.3.9.

Sadly the IOUYAP package there also contained the issue, in the end I resorted to good old fashioned tactics… I got hold of the source code from github and the issues I was facing were fixed in the version I checked out.  You can see the results below;

[toby@thebay GNS3-1.3.9]$ git clone https://github.com/GNS3/iouyap.git
Cloning into 'iouyap'...
remote: Counting objects: 78, done.
remote: Total 78 (delta 0), reused 0 (delta 0), pack-reused 78
Unpacking objects: 100% (78/78), done.
Checking connectivity... done.
[toby@thebay GNS3-1.3.9]$ ls
dynamips-0.2.14      gns3-gui-1.3.9      gns3-server-1.3.9      iouyap       iouyap-0.95.zip  ubridge-0.9.0.zip  vpcs-0.6.1.zip
dynamips-0.2.14.zip  gns3-gui-1.3.9.zip  gns3-server-1.3.9.zip  iouyap-0.95  ubridge-0.9.0    vpcs-0.6.1
[toby@thebay GNS3-1.3.9]$ cd iouyap
[toby@thebay iouyap]$ ls
config.c  dictionary.h  iouyap.c  iouyap.ini  Makefile  netmap.c  netmap_parse.y  README.rst
config.h  iniparser.h   iouyap.h  LICENSE     NETMAP    netmap.h  netmap_scan.l
[toby@thebay iouyap]$ make
gcc  -g -DDEBUG -Wall   -c -o iouyap.o iouyap.c
bison -y -d netmap_parse.y
mv -f y.tab.c netmap_parse.c
gcc  -g -DDEBUG -Wall   -c -o netmap_parse.o netmap_parse.c
flex  -t netmap_scan.l > netmap_scan.c
gcc  -g -DDEBUG -Wall   -c -o netmap_scan.o netmap_scan.c
gcc  -g -DDEBUG -Wall   -c -o netmap.o netmap.c
gcc  -g -DDEBUG -Wall   -c -o config.o config.c
gcc    iouyap.o netmap_parse.o netmap_scan.o netmap.o config.o  -liniparser -lpthread -o iouyap
rm netmap_scan.c netmap_parse.c
[toby@thebay iouyap]$ sudo make install
[sudo] password for toby:
chmod +x iouyap
sudo cp iouyap /usr/local/bin
sudo setcap cap_net_admin,cap_net_raw=ep iouyap

Taa Daa!

Linux Kernel Tweaks: kernel.core_uses_pid

Posted on Leave a commentPosted in Kernel Tuning, Linux

The sysctl option “kernel.core_uses_pid” comes into play when a vmcore file is being dumped.  It can be set in one of two ways;

kernel.core_uses_pid = 0

or

kernel.core_uses_pid = 1

As you can probably tell this is a binary settings.  It’s either enabled (1) or it’s not (0).

The exact text from the sysctl.txt file is;

==============================================================

core_uses_pid:

The default coredump filename is "core".  By setting
core_uses_pid to 1, the coredump filename becomes core.PID.
If core_pattern does not include "%p" (default does not)
and core_uses_pid is set, then .PID will be appended to
the filename.

==============================================================

For Fedora 22 this parameter is set to “1” by default.