SNMP request timeouts when NFS share on remote server is hanging

SNMP request timeouts when NFS share on remote server is hanging.

root# snmpwalk -v2c -cpublic localhost
Timeout: No Response from localhost
root#

A feature called skipNFSInHostResources was added to skip NFS mounts from filesystem lookup to prevent issues in case the remote resource is not available, from manpage of snmpd.conf:

skipNFSInHostResources true
controls whether NFS and NFS-like file systems should be omitted from the hrStorageTable (true or 1) or not (false or 0, which is the default).
If the Net-SNMP agent gets hung on NFS-mounted filesystems, you can try setting this to ‘1’.

The solution is to add the following entry “skipNFSInHostResources true” in /etc/snmp/snmpd.conf and restart snmpd service.

Add optional channels via mgr-sync SUSE Manager

I have found no way to add an optional channel via the web interface of SUMA 2.1. I needed to add Debuginfo-Pool for Kdump analysis which use crash. Crash utility is used to analyze the core file captured by kdump. It can also be used to analyze the core files created by other dump utilities like netdump, diskdump, xendump. You need to ensure the “kernel-debuginfo” package is present and it is at the same level as the kernel. So, I had to use a command line of SUMA.

suma:~ # mgr-sync list channels

--cut--
[I] SLES12-Pool for x86_64 SUSE Linux Enterprise Server 12 x86_64 [sles12-pool-x86_64]
[ ] SLE-Manager-Tools12-Debuginfo-Pool x86_64 SUSE Manager Tools [sle-manager-tools12-debuginfo-pool-x86_64]
[ ] SLE-Manager-Tools12-Debuginfo-Updates x86_64 SUSE Manager Tools [sle-manager-tools12-debuginfo-updates-x86_64]
[I] SLE-Manager-Tools12-Pool x86_64 SUSE Manager Tools [sle-manager-tools12-pool-x86_64]
[I] SLE-Manager-Tools12-Updates x86_64 SUSE Manager Tools [sle-manager-tools12-updates-x86_64]
--cut--

suma:~ # mgr-sync add channel sle-manager-tools12-debuginfo-pool-x86_64
Adding 'sle-manager-tools12-debuginfo-pool-x86_64' channel
Scheduling reposync for 'sle-manager-tools12-debuginfo-pool-x86_64' channel

suma:~ # mgr-sync add channel sle-manager-tools12-debuginfo-updates-x86_64
Adding 'sle-manager-tools12-debuginfo-updates-x86_64' channel
Scheduling reposync for 'sle-manager-tools12-debuginfo-updates-x86_64' channel
suma:~ #

suma:~ # mgr-sync refresh --refresh-channels
Refreshing Channels [DONE]
Refreshing Channel families [DONE]
Refreshing SUSE products [DONE]
Refreshing SUSE Product channels [DONE]
Refreshing Subscriptions [DONE]

Scheduling refresh of all the available channels
Scheduling reposync for 'sles11-sp3-pool-x86_64' channel
Scheduling reposync for 'sle11-sdk-sp3-pool-x86_64' channel
Scheduling reposync for 'sle11-sdk-sp3-updates-x86_64' channel
--cut--

Veeam unable to connect to a client machine, unable to negotiate with a client

When Veeam connects to a Linux machine, its use Diffie-Helman key exchange capabilities for successful secure connections and to reduce the possibility that a password will not be intercepted when authenticating to the storage.

If the client and server are unable to agree on a mutual set of parameters then the connection will fail. OpenSSH (7.0 and greater) will produce an error message like this:

sshd[11344]: fatal: Unable to negotiate with XXX.XXX.XXX.XXX port 36929: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1 [preauth]

In this case, the client and server were unable to agree on the key exchange algorithm. OpenSSH supports this method, but does not enable it by default because is weak and within theoretical range of the so-called Logjam attack. OpenSSH only disables algorithms that we actively recommend against using because they are known to be weak. In some cases, this might not be immediately possible so you may need to temporarily re-enable the weak algorithms to retain access.
Query SSH for the supported ciphers, key exchange algorithms and keyed-hash message authentication codes using the following command: “sshd -T | grep kexa

server:~ # sshd -T | grep kexa
kexalgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
server:~ #

And if there is no “diffie-hellman-group1-sha1” just add these:

KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

to your /etc/ssh/sshd_config file, and restart SSH.

server:~ # sshd -T | grep kexa
kexalgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
server:~ #

As you can see the only new added algorithm is called “diffie-hellman-group1-sha1”.

Find installation date and time of rpm package(s)

List all rpm package with date and time information, use the below given command to list all rpm package with date-stamp information:

rpm -qa --last

–cut
iotop-0.4.3-7.8.1 Fri Aug 7 12:24:02 2015
libgtop-lang-2.28.0-1.9.24 Fri Aug 7 12:20:57 2015
libgtop-2.28.0-1.9.24 Fri Aug 7 12:20:10 2015
libgtop-2_0-7-2.28.0-1.9.24 Fri Aug 7 12:20:06 2015
–cut

and for a single package:

rpm -q --last package-name

SUSE 12 – enable SSL and Create a Self-Signed Certificate

The SSL module is enabled by default in the global server configuration. In case it has been disabled on your host, activate it with the following command: a2enmod ssl. To finally enable SSL, the server needs to be started with the flag “SSL”. To do so, call a2enflag SSL (case-sensitive!). If you have chosen to encrypt your server certificate with a password, you should also increase the value for APACHE_TIMEOUT in /etc/sysconfig/apache2, so you have enough time to enter the passphrase when Apache starts. Restart the server to make these changes active. A reload is not sufficient.

Creating a Self-Signed Certificate on SUSE 12:

root# openssl req -new > vhostname.csr
root# openssl rsa -in privkey.pem -out vhostname.key
root# openssl x509 -in vhostname.csr -out journal.crt -req -signkey vhostname.key -days 3650

Copy the certificate files to the relevant directories, so that the Apache server can read them. Make sure that the private key /etc/apache2/ssl.key/vhostname.key is not world-readable, while the public PEM certificate /etc/apache2/ssl.crt/vhostname.crt is.

Delay and Delays in Postfix

Feb 8 12:46:24 relayserver postfix/smtp[21315]: 2vJLYX0Wghz7f3t: to=, relay=91.199.74.14[91.199.74.14]:25, delay=0.09, delays=0.01/0/0.04/0.05, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 200698166A)

If we take a look at the example email from above:

The delay parameter (delay=0.09) is fairly self explanatory, it is the total amount of time this email (2vJLYX0Wghz7f3t) has been on this server.
But what is the delays parameter all about?

delays=0.01/0/0.04/0.05

NOTE: Numbers smaller than 0.01 seconds are truncated to 0, to reduce the noise level in the logfile.

You might have guessed it is a break down of the total delay, but what do each number represent?

delays=a/b/c/d:
a=time before queue manager, including message transmission;
b=time in queue manager;
c=connection setup time including DNS, HELO and TLS;
d=message transmission time.

More explanation:

a (0.01): The time before getting to the queue manager, so the time it took to be transmitted onto the mail server and into postfix.
b (0): The time in queue manager, so this email didn’t hit the queues, so it was emailed straight away.
c (0.04): The time it took to set up a connection with the destination mail relay.
d (0.05): The time it took to transmit the email to the destination mail relay.

Rotate cron.daily on SUSE at a certain time.

At the moment my logs are rotating via logrotate at various different time.
To rotate at a certain time edit variable DAILY_TIME in /etc/sysconfig/cron

For example: DAILY_TIME="00:01"

Otherwise the way to do it involves making the creation time of /var/spool/cron/lastrun/cron.daily the hour and minute you want. This can be done by an at job since you don’t want to hang around to do that. To understand why creation time and not modification time, read /usr/lib/cron/run-crons, in particular the find statement.