Monday, June 19, 2017

Quick Re-Set for Desktop using xrandr

All too often when installing a game, a problem occurs that halts the game and does not restore my desktop to the proper size.

To look at what I used to have and what I wound up with is simple.

$ xrandr
Screen 0: minimum 8 x 8, current 2560 x 1024, maximum 8192 x 8192
DVI-I-0 disconnected primary (normal left inverted right x axis y axis)
DVI-I-1 disconnected (normal left inverted right x axis y axis)
DVI-I-2 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 376mm x 301mm
   1280x1024     60.02*+  75.02 
   1280x960      60.00 
   1152x864      75.00 
   1024x768      75.03    70.07    60.00 
   800x600       75.00    72.19    60.32    56.25 
   640x480       75.00    72.81    59.94 
DVI-I-3 connected 1280x1024+1280+0 (normal left inverted right x axis y axis) 376mm x 301mm
   1280x1024     60.02*+  75.02 
   1280x960      60.00 
   1152x864      75.00 
   1024x768      75.03    70.07    60.00 
   800x600       75.00    72.19    60.32    56.25 
   640x480       75.00    72.81    59.94 


So all I had to do was create a small shell script named restore to change the display back to the resolution I normally use, place it in ~/bin and make it executable.


#!/bin/sh
xrandr -s 2560x1024


Thursday, June 08, 2017

rsyslogd for Mageia6

I've been having trouble with occasional segfaults with my desktop workstation. It would be nice to look at the logs to see where the problem might be, but the logs show nothing.

It might be easier, I thought, if I enabled remote logging. That way I would have a copy of the desktops' logs on a working computer, a Shuttle X35 I use as a http server running lighttpd, serving static pages for several hobby-related websites.

Installing rsyslog was easy using urpmi. It was the configuration that was tricky. The configuration file for Mageia is kept in /etc/rsyslog.d and consists of a single file, 00_common.conf. The modules that can be called by rsyslog can be found in /usr/lib64/rsyslog.

The man page states:

The main configuration file /etc/rsyslog.conf or an alternative file,given with the -f option, is read at startup. Any  lines  that  begin with the hash mark (``#'') and empty lines are ignored. If an error occurs during parsing the error element is ignored. It  is  tried  to parse the rest of the line.
That seems easy enough. The receiving host is configured to receive and the sending host is configured to send, both using the same file. Using advice from TheGeekStuff, you can cobble together a file that might work. Note that that sites HOWTO page is dated 2012. The homepage for rsyslog also has rather extensive documents that tend to overwhelm.

One thing not found in the default 00_common.conf is the  "template" description that either generates the log file on the receiver, or configures rsyslog to send log info to the receiver.

RECEIVER

# This one is the template to generate the log filename #dynamically, depending on the client's IP address.
$template FILENAME,"/var/log/%fromhost-ip%/syslog.log"

SENDER

NOTE: 192.168.1.1 is used only as an example of the receiver's IP address.

# Provides UDP forwarding. The IP is the server's IP address
*.* @192.168.1.1:514 

# Provides TCP forwarding. But the current server runs on UDP
# *.* @@192.168.1.1:514

And, since I use sshutout and it needs to read /var/log/messages, the following needs to be added to the configuration file:

# Log info messages to messages file
#
*.=info;\
mail,news.none /var/log/messages

A FIX

If rsyslog will not start because of a missing dependency, it's because systemd is not configured correctly for rsyslog. This can be fixed with:

#systemctl enable rsyslog

Which creates the needed symlink.

ADDENDA

As of this writing, I have not gotten rsyslog to actually log anything remotely. I have configured the firewalls on each computer to allow the logging info to pass on port 514. Once I accomplish that, I will likely submit this information to the Mageia Wiki.

UPDATE - Oddly enough, the logs for my sender workstation are now included in my receiver workstation's /var/log/syslog. Weird.

RESOURCES









Wednesday, June 07, 2017

PS3 Six-Axis Controller with Qjoypad and Mageia6

The Linux kernel supports the PS3 Six-Axis controller out of the box. The trick now seems to be configuring it to work with your games.

Mageia provides the qjoypad tool which allows you to create "profiles" that map out the Six-Axis buttons switches and joysticks to keyboard keys which are mapped to you game. It does not provide pre-configured profiles.

It is a shame that there is no repository of profiles. As I construct profiles for the games I enjoy, I will make them available below.

Rather than futz with Bluetooth connectivity (since my PC does not have Bluetooth capabilities), I have settled for connection with a USB cable. Once connected, just press the PS button and the controller is recognized.

For Mageia, the device inputs are located in /dev/input. There you will find events 0-14, js0 and js1.

Before beginning, you should read the well-written documentation.


PROFILES:

RESOURCES:
Sixaxis Wikipedia Page

qjoypad Sourceforge Page

QJoyPad 3 Documentation

Qjoypad HOWTO


Building RPMs for Mageia - x2x

Occasionally, you may need to install something that is not included with Mageia. For instance, the x2x applications used to be included with Mageia, but has been dropped in Mageia 5. There are other packages, perhaps Ubuntu packages that I might want to use on my system. Or it's possible no package exists,  just a tarball.

Why would you want to build a package from source if the binary is already available? 

Let's begin with the Mageia Packagers RPM Tutorial as a reference.

Create Your Build Environment

It's always a good practice to build packages as a normal user, not as root. Still, it's handy to have sudo enabled for certain operations.

Create you build environment.

$ mkdir -p ~/rpmbuild/{SRPMS,SOURCES,SPECS,tmp}

Using your favorite editor, create the .rpmmacros file to build Mageia packages.
  
   # Only set %_topdir and %_tmppath if you want to ovveride the the default ~/rpmbuild 
   # and ~/rpmbuild/tmp
   #%_topdir                %(echo $HOME)/rpm
   #%_tmppath               %(echo $HOME)/rpm/tmp
   
   # If you want your packages to be GPG signed automatically, add these three lines
   # replacing 'your_name' with your GPG name. You may also use rpm --resign
   # to sign the packages later.
   %_signature             gpg
   %_gpg_name              your_name
   %_gpg_path              ~/.gnupg
   
   # Add your name and e-mail into the %packager field below. You may also want to
   # also replace vendor with yourself.
   %packager               John Doe 
   
   # you only need to set distribution and vendor if you are not building on
   # a mga host
   #%distribution           Mageia
   #%vendor                 Mageia.Org
   
   # If you want your packages to have your own distsuffix instead of mga (mga5 and older),
   # add it here like this
   #%distsuffix             foo
   
   # With mga6 and newer, if you want your packages to have your own dist instead of mga, 
   # add it here like this
   #%dist                   foo

We also need to install some packages like a compiler. I've found that installing the application checkinstall will bring in most everything we need. Checkinstall is a handy app used to create rpm files from tarballs and some scripts.

$ sudo urpmi checkinstall

Building From a Source RPM

To build from a source RPM file, we need to first install the source repositories.

$ sudo urpmi.addmedia core_src ftp://ftp.mirrror.com/mirror/mageia/distrib/5/SRPMS/core/release

 And then install it with

$ urpmi --install-src packagename

 You can also use ftp with urpmi. Since x2x was dropped (it has not been maintained in a while, circa 2003), we can search in RPMfind for the x2x packages (or go to the homepage for a tarball), and locate a suitable package. Also, we check that 1.30beta is the most current version available.

From this page we can follow the link to a 64-bit package and use the ftp feature of urpmi  to install the package as a regular user.

$ urpmi --install-src ftp://fr2.rpmfind.net/linux/Mandriva/devel/cooker/SRPMS/x2x-1.30-0.beta.7mdv2011.0.src.rpm

That should have worked, except that the files are so old, they have been deleted from the servers.  I eventually found a source rpm file at  http://pkgs.repoforge.org/x2x/x2x-1.27-0.2.rf.src.rpm , but it would not install due to missing dependencies (unsatisfied libXext-devel), therefore I used wget to download the file and I'll use urpmi to install the missing dependency and then install the source rpm.

Get  List of Dependencies Before Installing

There are several ways to get this information.

If you are installing a source rpm from the Mageia repository that you installeld above, then use

$ urpmq -d -m --sources

I find it easier if a source package is available, to use mc to peek inside the rpm file and look at the contents of comtents.cpio and examine the .spec file, which will list the dependencies. In this case, they are

 libX11-devel, libXext-devel, libXtst-devel, imake

But these are for a Fedora system, so the equivalent Mageia must be discovered.

 libx11-devel, libxext-devel, libxtst-devel, imake

Note how just the (annoying) difference in capitalization make things different. so

$sudo  urpmi libx11-devel libxext-devel libxtst-devel imake

Install these and the 17 packages that it takes to sort out all their dependencies. Ugh.


 ftp://fr2.rpmfind.net/linux/Mandriva/official/2011/SRPMS/contrib/release/x2x-1.30-0.beta.7mdv2011.0.src.rpm



REFERENCES

Mageia URPMI

Quick URPMI Reference

Mageia Packaging Tutorial

Checkinstall Homepage & README


Sunday, May 21, 2017

Killing the CAPS LOCK key

For some time, I have been interested in disabling the CAPS LOCK key. I frequently press it accidentally and it is a continuing aggravation. The old way of doing it no longer worked. I just set the task aside.

This will work.

Find the file in /etc/X11/xorg/conf.d that contains the "InputClass" section. Into that section, add

Option "XkbOptions" "caps:none"
Option "XkbOptions" "shift:both_capslock"

At the command line:

$ setxkbmap -option "caps:none"

$ setxkbmap -option "shift:both_capslock"

But that will not survive a reboot; the file edit above will or you can add it to rc.local.

Update: I have been unsuccessful using this in rc.local, so I created an entry in ~/.config/autostart that had both commands after EXEC= and that failed. It was not until I created two .desktop files, k1 and k2, that executed the commands in the proper order that it finally worked.

SOURCES 
https://www.linux.com/learn/hacking-your-linux-keyboard-xkb

Friday, March 31, 2017

Lighttpd and Simple Virtual Hosts Configuration.


I manage some websites for car clubs I belong to. They had been paying for web hosting and had some volunteers who knew not quite enough administrating the sites. Having some prior experience with these small club sites, I volunteered to host them and admin them.

With the first site, the pages were a train wreck of PHP and making even a small change on the existing pages caused the site to crash. Way back around the turn of the century, I had a few Linux user’s groups that wanted a website, so I worked with Cynthia Manuel of Flamingo Internet Navigators to make a template for a web site that would be easy to maintain and easy to add static content. She developed templates that relied on Server Side Includes (SSI) and Cascading Style Sheets (CSS) to make administration and content additions simple and easy, so I ported all the content over to that template and hosted the site myself. Later, another car club needed the same assistance and I ported it over as well.

The web server I chose initially was the venerable Apache web server. Setting up SSI was a little complicated, but not too bad, but Apache seemed like overkill and virtual hosts were a pain to configure. Enter the Lighttpd webserver.

Configuration for Lighttpd was pretty straightforward until it came time for virtual hosts, so here’s what I did to enable SSI and Virtual Hosts (vhosts) on the Lighttpd webserver. Part of the initial difficulty was that all the documentation available seemingly addressed older versions and it appears that the configuration options have changed quite a bit.

As of March, 2017, this guide applies to Lighttpd version 1.4.45. I currently have it running in a Mageia6 32-bit virtual machine. That makes backups easy and as simple as cloning the machine. As well, it makes moving it to a new host easy.

The HTML files for each website are kept at /var/www/html/xxxx and /var/www/html/yyyy. In this way, if anyone just uses the IP address instead of the domain name, they only get the standard default page whichs simply says It works!

To configure lighttpd for my use, it’s necessary to enable the modules I will be using by simply editing /etc/lighttpd/modules.conf and un-commenting the entries for SGCI and mod_simple_host.

To create the actual virtual hosts, I created a new directory, /etc/lighttpd/vhosts.conf and in that directory, I created two files, xxxx.conf and yyyy.conf.

In those files, I added the following information:

#xxxx.conf
$HTTP["host"] =~ "(^|\.)xxx\.com$" {
server.document-root = "/var/www/html/xxxx"
}

#yyyy.conf
$HTTP["host"] =~ "(^|\.)yyyy\.org$" {
server.document-root = "/var/www/html/yyyy"
}

To make those files available to the webserver, I needed to add the following to /etc/lighttpd/lighttpd.conf

include "vhosts.conf/xxxx.conf"
include "vhosts.conf/yyyy.conf"

There is, of course, much greater flexibility in writing these configuration files and many more features that can be enabled in Lighttpd and they are about as easy as my example. If you need more flexibility with virtual  hosts, it is possible to have the virtual hosts kept in a mysql database.

RESOURCES

Lighttpd Homepage


Lighttpd Docs


How to Support Configuration per Virtual Host
A more elaborate procedure to configure multiple virtual host with differing configurations.




Monday, December 12, 2016

Using FreeDOS to admin computer hardware

FreeDOS just released version 1.2, a small upgrade in functionality, mostly to be compatible with modern hardware.

ArchLinux has an excellent wiki that is easily applied to other Linux distros. Here is their discussion on using FreeDOS to flash a system BIOS and, interestingly, creating bootable DOS images that are bigger than standard floppy disk sizes. It offers step-by-step instructions on how to create a bootable CD using your FreeDOS image.

There's no need to repeat the wiki article here. I'll add more info if I develop more sources.

If you need an updated DOS memory extender, check this out.


RESOURCES:

FOSS DOS for 21st Century Hardware

FreeDOS

ArchLinux and FreeDOS

DOS4GW.EXE Version 2.01a and Alternative DOS Extenders