When you bring up at new LINUX OS installation it will typically [at least in the case of CentOS] have a route of 169.254/16 on every interface. These routes are used to support the good and virtuous feature known as "zeroconf". Sometimes however you do not want that route noise - especially if the host is going to be operating as a router or firewall. Fortunately disabling this feature for this specific use-case is easy.
# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
Text 1: The 169.254/16 route for zeroconf in the routing table.
Edit the /etc/sysconfig/network file and add a line reading "NOZEROCONF=yes". Then either restart the networking stack or reboot the host. No more zeroconf routes.
2014-01-23
2014-01-20
Concerning Decorators
Decorators are a powerful as well as arcanely constructed feature of Python. Over at is BLOG Graham Dumpleton has written a series of [8 so far] articles covering Python decorator's in-depth. Lots of information here along with abundant examples.
- How you implemented your Python decorator is wrong.
- Implementing a factory for creating decorators
- The interaction between decorators and descriptors.
- Implementing a universal decorator.
- Decorators which accept arguments.
- Maintaining decorator state using a class.
- The missing @synchronized decorator.
- The @synchronized decorator as context manager.
2014-01-19
The Quest For The Lost Pointer
On the screen you have a pointer - it points at thing! It is used to point at, select [highlight], drag, and numerous other things. The mouse pointer has been there and looked more-or-less the same for decades now; my pointer in GNOME Shell looks and works almost identically to the pointer I had on my GEOS desktop (1986). It has stayed the same because it works.
But the pointer has a few new challenges - (1) displays are getting bigger and bigger, big displays are aggregated together [you would have to have been very wealthy in 1986 to do that] and (2) the DPI/resolution of displays are now soaring to ridiculous and pointless values [not that the pointlessness suppresses the squeals of geeker joy from tech fanboys and fangirls]. These two trends raise the problem - "where the @*&# is the pointer?!". You look away from your vast panorama of high-DPI displays for just a moment... and then you have to find it again.
GNOME Shell provides two features that assist in the quest for the missing pointer.
The first is "Show location of pointer". This is most easily accessed via the GNOME Tweak Tool and is located in the "Keyboard and Mouse" section. Simply toggle the feature on. Once the feature is enabled tapping either Ctrl key [alone, by itself, not in combination with any other key] will cause the pointer to strobe; the location will immediately be apparent.
As with any setting you can also manage it using the GSettings API or using the gsettings command line tool. The path to the relevant key for "Show location of pointer" is "org.gnome.settings-daemon.peripherals.mouse/locate-pointer". To enable this feature from the command line:
The appropriate value is an integer - so look at the current value and tweak it up or down until you find a comfortable pointer size. You will notice that the change to a gsetting is immediate; there is not need to log-out or restart GNOME Shell.
If the command line is too intimidating for you - you can also adjust either of these configuration parameters, and a myriad of others, using the excellent dconf-editor GUI. For most parameters dconf-editor even provides a bit of documentation, the range of appropriate values, and the general-purpose default.
Now you never need to hunt for the pointer; you can spend more time hunting the whumpus.
But the pointer has a few new challenges - (1) displays are getting bigger and bigger, big displays are aggregated together [you would have to have been very wealthy in 1986 to do that] and (2) the DPI/resolution of displays are now soaring to ridiculous and pointless values [not that the pointlessness suppresses the squeals of geeker joy from tech fanboys and fangirls]. These two trends raise the problem - "where the @*&# is the pointer?!". You look away from your vast panorama of high-DPI displays for just a moment... and then you have to find it again.
GNOME Shell provides two features that assist in the quest for the missing pointer.
The first is "Show location of pointer". This is most easily accessed via the GNOME Tweak Tool and is located in the "Keyboard and Mouse" section. Simply toggle the feature on. Once the feature is enabled tapping either Ctrl key [alone, by itself, not in combination with any other key] will cause the pointer to strobe; the location will immediately be apparent.
As with any setting you can also manage it using the GSettings API or using the gsettings command line tool. The path to the relevant key for "Show location of pointer" is "org.gnome.settings-daemon.peripherals.mouse/locate-pointer". To enable this feature from the command line:
$ gsettings set org.gnome.settings-daemon.peripherals.mouse locate-pointer trueThe second setting is not available for modification in GNOME Tweak Tool or the standard control center. This is probably due the fact that you can render your desktop almost useless via senseless modification of this value. This second feature is the ability to adjust the size of the pointer - so for very high DPI displays you can increase the size of the pointer. You can also scale it down to where you cannot see the pointer at all [and if you do that, no, the software is not "broken"; the correct way to describe that condition is to say that the operator is "careless"]. The relevant setting is "org.gnome.desktop.interface/cursor-size".
$ gsettings get org.gnome.settings-daemon.peripherals.mouse locate-pointer
true
$ gsettings get org.gnome.desktop.interface cursor-size
24
$ gsettings set org.gnome.desktop.interface cursor-size 36
$ gsettings get org.gnome.desktop.interface cursor-size
36
The appropriate value is an integer - so look at the current value and tweak it up or down until you find a comfortable pointer size. You will notice that the change to a gsetting is immediate; there is not need to log-out or restart GNOME Shell.
If the command line is too intimidating for you - you can also adjust either of these configuration parameters, and a myriad of others, using the excellent dconf-editor GUI. For most parameters dconf-editor even provides a bit of documentation, the range of appropriate values, and the general-purpose default.
Now you never need to hunt for the pointer; you can spend more time hunting the whumpus.
2013-12-26
Translating...domain server....wait...be-frustrated
One of the most annoying features of Cisco's IOS is the assuming that anything you type which is not a command is a hostname. So...
... and when you are configuring a router which either (a) does not have DNS, (b) is on a network that is down, or (c) is on the workbench and not actually connected to a network - you get to enjoy the long pause of a DNS timeout.
Argh!
The solution is simple:
The "no ip domain-lookup" disables this feature. Now at least it fails instantly:
Note to self: everytime you pull a router out of storage - do this first.
Router#dev
Translating "dev"...domain server (255.255.255.255)
(255.255.255.255)
Translating "dev"...domain server (255.255.255.255)
....
... and when you are configuring a router which either (a) does not have DNS, (b) is on a network that is down, or (c) is on the workbench and not actually connected to a network - you get to enjoy the long pause of a DNS timeout.
Argh!
The solution is simple:
Router#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#no ip domain-lookup
Router(config)#exit
The "no ip domain-lookup" disables this feature. Now at least it fails instantly:
Router#devThe downside is that the router will no longer perform DNS look-ups to translate host names to addresses. That is bad for some specific use-cases [a VPN terminator is one possible example] - but generally that is not something that matters for a router. Once a router is configured you can always turn domain-lookup back on.
Translating "dev"
Translating "dev"
% Bad IP address or host name
% Unknown command or computer name, or unable to find computer address
Note to self: everytime you pull a router out of storage - do this first.
2013-12-18
PostgreSQL & Schemaless Data
In November [2013] I gave this presentation to the Grand Rapids Python User's Group [GRPUG]. This presentation followed another presentation which surveyed the offerings in the noSQL category of solutions.
This covers the significant support for schema-less data provided by PostgreSQL as well as SQLAlchemy's support for those features. This support is available in complete conjunction with PostgreSQL's many other proven and tested features:
 |
| PostgreSQL, SQLAlchemy, & Schemaless Data |
This covers the significant support for schema-less data provided by PostgreSQL as well as SQLAlchemy's support for those features. This support is available in complete conjunction with PostgreSQL's many other proven and tested features:
- replication mechanisms,
- support for table spaces,
- powerful CTEs
- foreign data wrappers
- GiS (now including path detection)
- And - of course - easily accessibility to all those features from a myriad of SQL clients and tools. You do not need to be a programmer/developer to reach them.
2013-12-14
Not Editing /etc/sysconfig/some-file
Many old guard UNIX admins, and their younger LINUX brethren, for reasons incomprehensible to every other sentient life form in the universe, believe that the lowly text file is the ultimate form of data representation. To hear some of them talk about system management a visting Europian could not be blamed to think that the text file is the crowning achievement of human civilization.
A technology company you might have heard of named Microsoft once had an operating system and a suite of applications that maintained most system and configuration information in text files - they called them "INI" files. There were little INI files everywhere as well as a few quite large INI files. A few included nice documentation as to what that part of the file meant and was for - at least until that documentation got deleted (it would let you do that, they were just text files after all). Microsoft realized what a mess that was and how difficult it was to manage more than a few machines when changing something meant editing all those files over and over again - and how easy it was to screw them up. So they came up with the idea of a "registry"; the registry was a hierarchical key-value data store [nothing wrong with that] with an API that could be used to query and change values. It would have been great. Except the implementation was terrible. The registry was this binary wad that became useless if something went wrong. And the tools to manage it were of "meh " quality at best.
Why does the registry matter when discussing UNIX/LINUX system administration? It matters because it is important to understand the distinction between a concept and an implementation. There is simply nothing wrong with the concept of the registry. There was a problem and the registry was a solution. But the implementation was bad - the implementation added a whole bunch of new problems. It is relevant because every time someone tries to discuss the same problem facing UNIX/LINUX administrator's still have - legions of unverifiable and mostly undocumented text files - they will get the story of the Microsoft registry thrown in their face. But - concept vs. implementation - that argument against how most UNIX/LINUX administration works is complete fallacious. The fact remains that editing or patching configuration files is a dangerous business as likely to break things as to improve them.
At least now many of the configuration files are gathered together in /etc/sysconfig. Much of a system's basic configuration - such as the display manager, network configuration, etc... - can be managed by changing stuff in /etc/sysconfig. That is an improvement. But automating changes is still a business of tweaking text files.
Fortunately uses of SuSE and openSUSE have an escape route. One of the best features of openSUSE is YaST - YaST is "Yet another Setup Tool" with the important distinction that it (a) works, (b) is comprehensive, and (c) does not degrade your system's security. YaST has an excellent tool for editing all the common /etc/sysconfig relating things. YaST will run on the console [TUI], on your desktop [GUI], or you can access it via your browser [HTTP]. All well and good - but if you need to automate/script setting up a host ... All the aforementioned stuff still requires interacting with a user interface; it still is not as beautiful as an API.
... or maybe ....
Huh, would you look that that. There are all the documented /etc/sysconfig related directives. I just dumped them to standard out using a tool. I wonder if I can see the current value of a given directive and the related documentation?
Nice! And if I want to change the value?
Shucks, that is almost as good as an API! So I can dump for backup or reference my current /etc/sysconfig related configuration to a single document? Yes. I can query a setting's value? Yes [without using grep and a regular expression!]. And I can change a setting without using vim? Yes. openSUSE users have yet another reason to be smug while users of other distributions do battle with vim? Yes.
What was by original though? Ah, of course: having to edit text files as the primary means of systems administration is failure. Fortunately we have YaST, and our lives now include less failure and more tool-based automation [aka "success"].
A technology company you might have heard of named Microsoft once had an operating system and a suite of applications that maintained most system and configuration information in text files - they called them "INI" files. There were little INI files everywhere as well as a few quite large INI files. A few included nice documentation as to what that part of the file meant and was for - at least until that documentation got deleted (it would let you do that, they were just text files after all). Microsoft realized what a mess that was and how difficult it was to manage more than a few machines when changing something meant editing all those files over and over again - and how easy it was to screw them up. So they came up with the idea of a "registry"; the registry was a hierarchical key-value data store [nothing wrong with that] with an API that could be used to query and change values. It would have been great. Except the implementation was terrible. The registry was this binary wad that became useless if something went wrong. And the tools to manage it were of "
Why does the registry matter when discussing UNIX/LINUX system administration? It matters because it is important to understand the distinction between a concept and an implementation. There is simply nothing wrong with the concept of the registry. There was a problem and the registry was a solution. But the implementation was bad - the implementation added a whole bunch of new problems. It is relevant because every time someone tries to discuss the same problem facing UNIX/LINUX administrator's still have - legions of unverifiable and mostly undocumented text files - they will get the story of the Microsoft registry thrown in their face. But - concept vs. implementation - that argument against how most UNIX/LINUX administration works is complete fallacious. The fact remains that editing or patching configuration files is a dangerous business as likely to break things as to improve them.
At least now many of the configuration files are gathered together in /etc/sysconfig. Much of a system's basic configuration - such as the display manager, network configuration, etc... - can be managed by changing stuff in /etc/sysconfig. That is an improvement. But automating changes is still a business of tweaking text files.
Fortunately uses of SuSE and openSUSE have an escape route. One of the best features of openSUSE is YaST - YaST is "Yet another Setup Tool" with the important distinction that it (a) works, (b) is comprehensive, and (c) does not degrade your system's security. YaST has an excellent tool for editing all the common /etc/sysconfig relating things. YaST will run on the console [TUI], on your desktop [GUI], or you can access it via your browser [HTTP]. All well and good - but if you need to automate/script setting up a host ... All the aforementioned stuff still requires interacting with a user interface; it still is not as beautiful as an API.
... or maybe ....
$ sudo /sbin/yast2 sysconfig list all
All Variables:
ACPI_DSDT=""
APACHE_ACCESS_LOG="/var/log/apache2/access_log combined"
APACHE_CONF_INCLUDE_DIRS=""
APACHE_CONF_INCLUDE_FILES=""
APACHE_EXTENDED_STATUS="off"
APACHE_HTTPD_CONF=""
...
Huh, would you look that that. There are all the documented /etc/sysconfig related directives. I just dumped them to standard out using a tool. I wonder if I can see the current value of a given directive and the related documentation?
$ sudo /sbin/yast2 sysconfig details variable=DISPLAYMANAGER_AD_INTEGRATION
Description:
Value: yes
File: /etc/sysconfig/displaymanager
Possible Values: yes,no
Default Value: no
Description:
Display a combobox for Active Directory domains.
Nice! And if I want to change the value?
$ sudo /sbin/yast2 sysconfig set variable=DISPLAYMANAGER_AD_INTEGRATION value=yes
Setting variable 'DISPLAYMANAGER_AD_INTEGRATION' to 'yes': Success
Shucks, that is almost as good as an API! So I can dump for backup or reference my current /etc/sysconfig related configuration to a single document? Yes. I can query a setting's value? Yes [without using grep and a regular expression!]. And I can change a setting without using vim? Yes. openSUSE users have yet another reason to be smug while users of other distributions do battle with vim? Yes.
What was by original though? Ah, of course: having to edit text files as the primary means of systems administration is failure. Fortunately we have YaST, and our lives now include less failure and more tool-based automation [aka "success"].
2013-12-08
Easy Connect Without Auto Connect
As a Network & System Administrator you deal with a lot of different networks. Increasingly even a single geographic spot has multiple networks - a physical ethernet network, a 'trusted' wireless network with strong AAA, a 'guest' network with a simple shared secret, and possibly a management vLAN running behind the innermost ring of firewalls [allowing access to Hypervisors, SAN administrative interfaces, climate control systems, etc...]. GNOME's excellent network manager makes it simple to have many network profiles and manage all the networks you may connect to through various means [physical ethernet, wireless, VPN, ...]. But
one frustration is that it will usually 'default' to a network if the automatically-connect option in the network manager profile has been selected. Which I suppose is a feature, not a bug; but invariably that will be the wrong network for what you need to do that day. Then you're applications have already started, your browser has detected it's proxy settings, and you are on the wrong network. Argh!
Facing this dilemma when working for a couple days on a nest of layered networks an obvious solution presented itself. I simply set all networks to not connect automatically. Simple - yet annoying. Because now every time I login I have to the GNOME Control Center's Network tool and select a network. That step gets old when you have to do it almost every time you login. But a simple solution to that is also available - setup the Network tool to launch upon login.
Applications can be added to the "Startup Programs" list using the gnome-session-properties tool. Select the "Startup Programs" tab (a very clever name!) and click "Add". I added a "GNOME Control Center: Network" entry which runs "gnome-control-center network". That starts the GNOME Control Center's Network tool every time I log in - so the dialog is presented and I can easily select the network, if any, that I need to connect to. If I do not need to connect to any network I can just dismiss the dialog.
Now nothing gets connected automatically but connecting, if desired, is only a click or two.
 |
| GNOME's gnome-session-properties tool. |
Facing this dilemma when working for a couple days on a nest of layered networks an obvious solution presented itself. I simply set all networks to not connect automatically. Simple - yet annoying. Because now every time I login I have to the GNOME Control Center's Network tool and select a network. That step gets old when you have to do it almost every time you login. But a simple solution to that is also available - setup the Network tool to launch upon login.
 |
| GNOME's Network Control Center tool. |
Now nothing gets connected automatically but connecting, if desired, is only a click or two.
Subscribe to:
Posts (Atom)