Just another Scott Alan Miller Sites site

To get remote access to the graphical tools of Linux Mint, simply connect via SSH with the X and c flags (to tunnel X protocol and add compression.)  Once you do this (presumably from another UNIX system) you can simply run commands from the new session to large a local view of remote graphical applications.  This can make many tasks much easier.

ssh -XC mylogin@remoteserver

For example, should you want to make changes to the remote Linux Mint desktop you can do so via graphical tools.  To use the standard System Settings dialogue, just run this command:

gnome-control-center &

Often remote SSH logins on Linux can experience a lengthy delay.  This is often caused by the SSH daemon on the server defaulting to attempting a DNS lookup of the SSH client attempting to connect to it.  Typically we do not want this behaviour as client systems often cannot be verified in this manner but awaiting a DNS timeout can be rather annoying.  Many systems configure this on by default.  I see this in the Red Hat family including RHEL, CentOS, etc.

The fix is simple, just explicetly add the line:

UseDNS no

To the /etc/ssh/sshd_config configuration file.  The default is “yes” and there should be a comment to this effect as well.  After making the change, simply restart the SSH daemon for the change to take effect.

service sshd restart

IPTables is, without a doubt, one of the more frustrating components of Linux administration.  It is pretty much ubiquitous in need but documentation is often lacking and the differences in de facto use between distributions can create a degree of complexity that should be wholly unnecessary for such a common system function.  Red Hat (and ergo CentOS) uses its own tools to alter IPTables which, if you are limited to very basic needs as can be address pretty easily.  The Red Hat tools are great for doing the every day tasks like opening a needed port.

However, it is not uncommon to need a lot more flexibility in IPTables and once that is necessary the Red Hat tools make the job for more cumbersome and less portable.  For my own firewall administration I have moved to creating my own configuration file and loading it manually into IPTables.

You can put your configuration file anywhere that you want.  In etc makes sense, or in var, perhaps.  This is not the final configuration file, just an interim, so it is acceptable to keep in the var filesystem.

In this IPTables configuration file, you can place standard IPTables commands in the following format:

-bash-3.2$ sudo head /var/iptables_primary
-A INPUT -s 1.0.0.0/255.0.0.0 -j DROP 
-A INPUT -s 2.0.0.0/255.0.0.0 -j DROP
-A INPUT -s 3.0.0.0/255.0.0.0 -j DROP
-A INPUT -s 4.0.0.0/255.0.0.0 -j DROP
-A INPUT -s 5.0.0.0/255.0.0.0 -j DROP
-A INPUT -s 6.0.0.0/255.0.0.0 -j DROP
-A INPUT -s 7.0.0.0/255.0.0.0 -j DROP
-A INPUT -s 9.0.0.0/255.0.0.0 -j DROP
-A INPUT -s 11.0.0.0/255.0.0.0 -j DROP
-A INPUT -s 12.0.0.0/255.0.0.0 -j DROP

This makes it very easy to test and modify your IPTables settings because the commands that you use to modify IPTables on the fly are exactly the same commands that you put into this file.  Now to actually use this file, we simply need to read it in line by line.  If you want to be sure that IPTables is in a clean state, stop it first and then load this file.  Don’t forget to save when you are done.  I’ll use the built in Red Hat / CentOS service commands below for the example.

service iptables stop
while read line; do iptables $line; done < /var/iptables_primary
service iptables save

And with that, your new IPTables configuration should be up and running and easy to edit.

Making configuration changes to the settings of a network interface card is not one that we typically do on an average day but it can be an important component of network performance tuning.  The most common change that we might need to make is to increase the receive (RX) ring buffer size.  Most often we will find that the ring buffer is set rather small and might need to be increased on systems that are receiving a high volume of network traffic.

We can examine our current and available NIC settings using the ethtool command combined with the -g flag.

# ethtool -g eth0
Ring parameters for eth0:
Pre-set maximums:
RX:             2040
RX Mini:        0
RX Jumbo:       8160
TX:             255
Current hardware settings:
RX:             255
RX Mini:        0
RX Jumbo:       0
TX:             255

Here we have two sections in our output.  The first section is “Pre-set maximums” which tells us the maximum values that could be set for each available parameter.  The second section shows us to what each parameter is currently set.  We are most interested in the top most parameter labeled simply “RX” which is our receive ring buffer.

Buffers are generally tuned small for latency reasons.  The smaller the buffer the lower the latency.  But low latency comes at a price and that price is maximum throughput.  For greater throughput we need a larger buffer.  Factory defaults are good, generally, for most systems but don’t be afraid to tune this for your own scenario.

To modify the current parameter settings we use the -G flag as opposed to the -g flag used to read them.  A common setting is to set the RX parameter to 1020.  Here is the command to do that:

# ethtool -G eth0 rx 1020

The change will take affect immediately and requires no restart to your system or even your network stack.  Read your current settings again with -g to verify the change.

Remember that these changes made with ethtool are being made to the network card itself and not to the operating system.  We are not changing the kernel network stack parameters but the NIC parameters in the firmware.