Wednesday, May 18, 2016

Adding a Spellchecker to Leafpad


Leafpad is the text editor for the LXDE desktop environment. It does well for editing basic text files, but it lacks a spellchecker.

This is a hack to use the default-installed Hunspell to spell-check your text file.

To accomplish this, you need to save the text file, open it in Hunspell, close Hunspell and re-open the document in Leafpad.

This is accomplished by a script added to your .bashrc. I found this script in a recent Knoppix thread.

Add this to .bashrc:

lpad() { # uses leafpad to edit $1; on closing leafpad, # # # hunspell checks spelling; 
#on closing hunspell, leafpad shows corrected copy.
leafpad $1; aspell $1; leafpad $1 &
}

NOTE: You can also use this with ispell, but you'll need to invoke "ispell  -c".

NOTE: I found the command line at the bottom of Hunspell to be misleading. For example, it says that pressing "I" is "Insert". It actually means "Accept  the  word,  capitalized as it is in the file, and update private dictionary."  As well, "U" is "Uncap". It actually means "Accept the word, and add an uncapitalized (actually,  all lower-case) version to the private dictionary." "X" causes you to exit the file with no changes and "Q" causes you to exit, discarding any changes you have already made.

NOTE: Hunspell keeps its dictionaries in /usr/share/hunspell and by default two additional dictionaries are installed. I have found that these other dictionaries, en_CA and en_GB, often confuse Firefox and that is solved easily by deleting all but the en_US files.


RESOURCES






Sunday, May 15, 2016

Using a Blocklist File With Iptables

I read an interesting piece about securing servers written by Greg Bledsoe in LinuxJournal. I thought I would try it out and it turns out that it needed a few massages to make it run on my Mageia5 system.

There are two parts to his approach, a short script that runs as rc.local, which file does not exist in Mageia, but will be properly run if you create it in /etc/rc.d/rc.local.

#!/bin/sh
#/etc/rc.d/rc.local
# REF: http://www.linuxjournal.com/content/server-hardening?page=0,2
#create iptables blocklist rule and ipset hash
/usr/sbin/ipset create blocklist hash:net
/usr/sbin/iptables -I INPUT 1 -m set --match-set blocklist 
↪src -j DROP

This file owner should be root with 700 permissions.

Once you create it, you should execute it manually because that needs to be done before you run the script to collect the blocklists.

I put the blocklist collection script in /usr/local/bin. You will need to create the directory /usr/local/bin/tmp because the script wants to keep its temporary files there.


#!/bin/bash
#/usr/local/bin/getblocklist
# REF: http://www.linuxjournal.com/content/server-hardening?page=0,2

PATH=$PATH:/sbin
WD=`pwd`
TMP_DIR=$WD/tmp
IP_TMP=$TMP_DIR/ip.temp
IP_BLOCKLIST=$WD/ip-blocklist.conf
IP_BLOCKLIST_TMP=$TMP_DIR/ip-blocklist.temp
list="chinese nigerian russian lacnic exploited-servers"
BLOCKLISTS=(
"http://www.projecthoneypot.org/list_of_ips.php?t=d&rss=1" # Project 
 ↪Honey Pot Directory of Dictionary Attacker IPs
"http://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=1.1.1.1"  
 ↪# TOR Exit Nodes
"http://www.maxmind.com/en/anonymous_proxies" # MaxMind GeoIP 
 ↪Anonymous Proxies
"http://danger.rulez.sk/projects/bruteforceblocker/blist.php" 
 ↪# BruteForceBlocker IP List
"http://rules.emergingthreats.net/blockrules/rbn-ips.txt" 
 ↪# Emerging Threats - Russian Business Networks List
"http://www.spamhaus.org/drop/drop.lasso" # Spamhaus Dont Route 
 ↪Or Peer List (DROP)
"http://cinsscore.com/list/ci-badguys.txt" # C.I. Army Malicious 
 ↪IP List
"http://www.openbl.org/lists/base.txt"  # OpenBLOCK.org 30 day List
"http://www.autoshun.org/files/shunlist.csv" # Autoshun Shun List
"http://lists.blocklist.de/lists/all.txt" # blocklist.de attackers
)

cd  $TMP_DIR
# This gets the various lists
for i in "${BLOCKLISTS[@]}"
do
    curl "$i" > $IP_TMP
    grep -Po '(?:\d{1,3}\.){3}\d{1,3}(?:/\d{1,2})?' $IP_TMP >> $IP_BLOCKLIST_TMP
done
for i in `echo $list`; do
    # This section gets wizcrafts lists
    wget --quiet http://www.wizcrafts.net/$i-iptables-blocklist.html
    # Grep out all but ip blocks
    cat $i-iptables-blocklist.html | grep -v \< | grep -v \: | grep -v \; | grep -v \# | grep [0-9] > $i.txt
    # Consolidate blocks into master list
    cat $i.txt >> $IP_BLOCKLIST_TMP
done

sort $IP_BLOCKLIST_TMP -n | uniq > $IP_BLOCKLIST
rm $IP_BLOCKLIST_TMP
wc -l $IP_BLOCKLIST

ipset flush blocklist
egrep -v "^#|^$" $IP_BLOCKLIST | while IFS= read -r ip
do
        ipset add blocklist $ip
done

#cleanup
rm -fR $TMP_DIR/*

exit 0

This file owner should be root with 700 permissions.

Check your script and remove the " ↪" symbols, re-connecting the comments to the line above them.

Now manually execute the script. It should run and exit, creating the blockhost.conf file that the first script above will execute.

The final step is to add the second script in your crontab to run once a day.

All Done. Remember to read the entire article.

Friday, May 06, 2016

ImageMagick Interim Fix

A vulnerability resides in ImageMagick, a widely used image-processing library that's supported by PHP, Ruby, NodeJS, Python, and about a dozen other languages. Many social media and blogging sites, as well as a large number of content management systems, directly or indirectly rely on ImageMagick-based processing so they can resize images uploaded by end users. According to developer and security researcher Ryan Huber, ImageMagick suffers from a vulnerability that allows malformed images to force a Web server to execute code of an attacker's choosing. Websites that use ImageMagick and allow users to upload images are at risk of attacks that could completely compromise their security.

Update your /etc/ImageMagick/policy.xml file so that it contains the code taken from http://imagetragick.com  and restart corresponding daemons.

You're safe now. The full fix is still being worked out.

And if you have the old version of ImageMagick (because you are on CentOS 5, for example) which doesn't support policy.xml, you can edit delegates.xml, by removing all delegates just to be safe. The file will be somewhere around: /usr/lib64/ImageMagick-6.2.8/config/

RESOURCES
https://en.wikipedia.org/wiki/ImageMagick

https://it.slashdot.org/story/16/05/06/1516254/huge-number-of-sites-imperiled-by-critical-image-processing-vulnerability

http://fmwconcepts.com/imagemagick/

In a terminal type
$ display
and the ImageMagick native GUI appears.
If you want to create an application luncher with the logo then the icon is in the folder
/usr/share/doc/imagemagick/www/Magick++/ImageMagick.png

Tuesday, May 03, 2016

Installing Unreal Tournament 2003 on a 64-bit Modern System

In 2003, I was elated that Unreal Tournament 2003 came with a Linux installer (on Disc 3). All I had to do was run the installer and play the game.

Nowadays, it's not so easy. Linux is not like it was in 2003. Not only has it improved. but it includes tools to allow backwards compatibility.

We'll be installing as root to make the game available to all system users.

First, we need to set a usable POSIX value.

# export _POSIX2_VERSION=199209

The set a usable libc version.

# export SETUP_LIBC=glibc-2.1

Then tell the installer that we are running on a 32-bit system.

# linux32 ./linux_installer.sh

Modify the ut2003 startup script in /usr/local/games/ut2003 with the above information.

Then just use the graphical installation tool, provide you CD key and play the game.



Sunday, April 10, 2016

Creating a chroot Environment for Mageia

Mageia documents how to set up a chroot environment in their Wiki. We'll set up both a 32-bit and a 64-bit environment for both the current release as well as the development branch, Cauldron, and eventually use them with schroot, a tool that makes managing chrooted environments much, much easier.

To summarize the steps to create a chroot using urpmi as follows:

Create a Mount Point
To create the mountpoint for the chroot environment for either or both 32- and 64-bit environments as well as Cauldron:
# mkdir -p /mnt/chroot/mageia32
# mkdir -p /mnr/chroot/mageia64
# mkdir -p /mnt/chroot/cauldron32
# mkdir -p /mnt/chroot/cauldron64

Mageia can use either package set with your native urpmi application to install packages in the chrooted environment.

32-bit chroot
For the 32-bit environment:
Add the repositories.
$ sudo urpmi.addmedia --distrib --urpmi-root /mnt/chroot/mageia32  --mirrorlist 'http://mirrors.mageia.org/api/mageia.5.i586.list' 

$ sudo urpmi.addmedia --distrib --urpmi-root /mnt/chroot/cauldron32  --mirrorlist 'http://mirrors.mageia.org/api/mageia.cauldron.i586.list' 

Install the base system:
$ sudo urpmi --urpmi-root /mnt/chroot/mageia32 basesystem urpmi locales-en mc wget openssh-server

$ sudo urpmi --urpmi-root /mnt/chroot/cauldron32 basesystem urpmi locales-en mc wget openssh-server

64-bit chroot
For a 64-bit environment:
Add the repositories.
$ sudo urpmi.addmedia --distrib --urpmi-root /mnt/chroot/mageia64  --mirrorlist 'http://mirrors.mageia.org/api/mageia.5.x86_64.list'

$ sudo urpmi.addmedia --distrib --urpmi-root /mnt/chroot/cauldron64  --mirrorlist 'http://mirrors.mageia.org/api/mageia.cauldron.x86_64.list'

Install the base system:
$ sudo urpmi --urpmi-root /mnt/chroot/mageia64 basesystem urpmi locales-en mc wget openssh-server 

$ sudo urpmi --urpmi-root /mnt/chroot/cauldron64 basesystem urpmi locales-en mc wget openssh-server 

Make the Environments Usable
These next few steps are not needed if you will be using schroot. If not using schroot, you need to make these environments usable, so you need to provide DNS information so networking can be used by copying /etc/resolve.conf to the appropriate location in the chroot.

You also need to have a working /proc filesysten.
# mount -o bind /proc /mnt/chroot/mageia [cauldron][32][64]/proc

You would also use this technique to access your host filesystem from within the chrooted environment by mounting it inside the chroot.

Using the chroot Environment
The Mageia wiki for chroot offers straightforward instructions as to how to ssh into your chroot environment and won't be repeated here. It also offers advice on launching X clients from the chrooted environment.

schroot
At this point, it is worth exploring the advantages that schroot offers for managing and manipulating your chrooted environments. To Be Continued . . .

RESOURCES

Mageia Wiki for chroot

Mageia QA procedure for evaluating schroot

Magiea URPMI Wiki Entry

Debian Wiki Schroot HOWTO

Schroot Build Environment Setup

Schroot Mageia Configuration



Saturday, April 09, 2016

Installing and Configuring a Mediawiki wiki on Mageia5

I started a MediaWiki wiki for my hobby, to serve as a convenient place to collect and centralize all the bits of information that I find scattered about the internet.

Creating such a wiki can be a daunting task, but if broken down into small tasks, it can be done. The most difficulty I had was that there were no specific instructions for Mageia. The best general instructions I could find were from the Mediawiki site, but were  for Ubuntu. Mageia configures its default configurations slightly different.

I chose to tun the wiki and its associated webserver and database in a virtual machinate using VirtualBox, so we can tackle that first assuming that you already know how install and configure VirtualBox.

Installing A Minimal Mageia Base
During the installation, deselect all the pre-configured options, but do select the option to select individual packages. You will select a minimal install with no X11 or documentation, but with urpmi.

The remaining installation is pretty straightforward and quick. On re-booting, you will see a prompt; you can log in as root. At this point, you'll need to use vi to edit files, so brush up if your vi-fu is rusty.

Modify /etc/group to add your personal account as a member of the wheel group and modify /etc/sudoers to you liking as to whether or not a password will be required.

Then we will remove the DVD-based repositories, add some web-based ones, perform and update of our base system, and then install the additional applications we need.

# urpmi.removemedia -av

# urpmi.addmedia --distribute --moralist 'http://mirrors.mageia.org/api/mageia.5.x86_84.list'

# urpmi --replacefiles --auto-update --auto -v && urpmi --replacefiles --auto-update --auto -v && shutdown -r now

The last instruction to run the command twice is at the suggestion of Mageia when doing a distro upgrade. here, it's just added insurance that all the files will be updated before you reboot.

Install Something to Send Mail From Your Wiki
We will need an application to send mail from our wiki. Rather than use a heavyweight like sendmail, I prefer the very lightweight /bin/mail, and that requires some additional configuration.

# urpmi mailx

Make the system's /etc/alternatives aware of /bin/mail and make it the default selection.

# update-alternatives --install /etc/alternatives/sendmail-command sendmail-command /bin/mail 1 

I needed to configure /etc/nail.rc to accommodate  my Gmail account.

Install Needed and Useful Applications
Let's add a few things to make it easier on ourselves. We need an ssh sever so we can log in remotely (actually while we log in from the host while the server runs in headless mode) and my favorite file manager, the Midnight Commander.

# urpmi openssh-server mc

Now it's time to not only install MediaWiki, but all the things that will be needed. In the Ubuntu tutorial and in the web-based MediaWiki setup procedure you will follow later, you will learn what you need, but here it is all laid out beforehand to make our job easier.

# urpmi task-lamp php-apc mediawiki-mysql git imagemagick 

Configure PHP
The /etc/php.ini file needs to be modified to reflect your timezone and allow large files to be uploaded. Here's the examples:

Date]              
; Defines the default timezone used by the date functions  
; http://php.net/date.timezone  
;date.timezone = "US/Eastern"

That web address will help you locate the appropriate value for the timezone.

; Maximum allowed size for uploaded files.
; http://php.net/upload-max-filesize 
upload_max_filesize = 20M

Configure Apache
Apache is installed with some good and useful pre-made configurations, but at the advice of MediaWiki, we should make the image upload directory more secure so bad actors can't do bad things.  

Edit /etc/httpd/conf/sites.d/mediawiki.conf to add:  
         
    # Ignore .htaccess files 
    AllowOverride None      
    # Serve HTML as plaintext, don't execute SHTML 
    AddType text/plain .html .htm .shtml .php .phtml .php5 
    # Don't run arbitrary PHP code.    
    php_admin_flag engine off      
    # If you've other scripting languages, disable them too.    

Start Apache : # systemctl start httpd.service

Start MySQL: # systemctl start mysqld.service

Make MySQL Safer
You should launch a special configuration application to make the MySQL server more secure and establish a root password.

# mysql_secure_installation

Configure MediaWiki
The initial configuration of our MediaWiki is done through a  web-based interface. This is fine if you're installing it on real hardware, but we're doing it on a headless virtual server with no X server. Theoretically, it should be possible to install a modern web browser like Firefox on our headless, X-less sever (it's only an X client after all) and run it over ssh on our local X-server.

Use ssh to access the server, install and launch Firefox to start the MediaWiki configuration.

During the web-based configuration, take the time to read everything it says and understand everything it says and make a note of every entry you make.

By the way, if you futz up at this point, just delete that one file and begin the web-based configuration again. It can be found at /etc/mediawiki/.

One Last Thing
We need to have good security for our server since it will face the Internet. To do this, we'll use Mageia's msec tool and we'll uninstall all applications we will no longer be using.

# urpmi msec && msec -l server
# urpme firefox && urpme --auto-orphans

Access Your New Wiki
Now here's the thing, the URL to access you new wiki is http://yourdomain/mediawiki. There are some valid reasons for making it so, but it's awkward. My workaround is to edit the default Apache file index.html to become a "welcome page" with a link to the funky address of the wiki.

Make Your URLs Pretty
If you don't like the ugly PHP URLs, you can find instructions on how to modify Apache to show prettier URLs. I didn't feel the need to do that.

Make a Custom Logo
The default logo for your site is located at /usr/share/mediawiki/skins/common/images/wiki.png. 
Make you own logo, name it wiki.png and replace the default logo.

REFERENCES

Installation Requirements

Installation Guide

System Administration

Running MediaWiki on Ubuntu  <-- followedl="" good.="" i="" it="" p="" pretty="" s="" what="">

Saturday, March 05, 2016

Lying to Get the Job Done: Adventures in setarch and export

It says something about the power and flexibility Linux when you are provided a means to lie in order to get an application to execute. And by this, I mean using the setarch command and a few other tricks to fool an application created for an older system so it will run on more modern system architectures.

I'm occupying myself trying to install some old games and so far, it has been challenging. In the heady turn-of-the-Millineum days, Linux installers were all the rage, promoted by Loki, a company the developed the installers and produced Linux versions of then-popular games, but wound up in Chapter 7 bankruptcy. Even in the throes of  their demise they didn't forget the Linux gaming community and made their installers and the GPL source code available for the world to use. That would be great had not fewer and fewer servers carried the actual (now-old) files -- most of the links are dead -- and had not the development of Linux progressed so much. Many of their *.run installation scripts can be downloaded from the author, Icculus.

For example, Unreal Tournament 2003 was shipped with a Linux installer on disc 3, but it won't execute on a modern Linux. The installer itself is created with makeself which is still available, but
"Archives created with Makeself prior to v2.1.2 were using an old syntax for the head and tail Unix commands that is being progressively obsoleted in their GNU forms. Therefore you may have problems uncompressing some of these archives. A workaround for this is to set the environment variable $_POSIX2_VERSION to enable the old syntax, i.e. : export _POSIX2_VERSION=199209."

 It is possible to launch the *.run file with useful arguments.
--help
          displays the full list of arguments

--list
          lists the contents of the archive
--target
          extracts the contents of the archive to



but does not install anything
It's also possible to extract the archive, add files to it like special config files, updated binaries, add-ons and game data files, and recreate the *.run archive for your personal use.
So using that trick works and I can now list the contents of the .run file without a checksum error, but it won't install anything because of a glibc mismatch. 

That, however, can be fixed by invoking:

export SETUP_LIBC=glibc-2.1.

We're still not out of the woods because the installer checks the environment and, of course, balks at our powerful, modern 64-bit, kernel 4.x, multi-gigabyte RAM, multi-processor miracles of the modern age.

The fix for that is the setarch application. It deceives the application by feeding it bogus uname information. Not that it does not provide an actual environment, it just feeds information you can choose to the application so that it believes it is running in the appropriate environment.

If the application needs specific version of older libraries, you are still required to actually supply those. 

setarch deceives  about libnux32, linux64, i386, i486, i586, i686, athlon and x86_64 , can tell the app that we're running kernel 2.6, can deceive about the amount of available RAM available and other devious things.

Finally, I was able to use the old, creaky installer on the CD by invoking


$ export _POSIX2_VERSION=199209 && export SETUP_LIBC=glibc-2.1. && linux32 ./linux_installer.run

I expect to have use more deception to get the binaries to run. For example. to run Quake with sound, I had to create a wrapper script and execute SDL_AUDIODRIVER=dsp prior to executing the game binary.
If you run into these kinds of problems, now you can lie as well. It's all lies from now on.

RESOURCES



DRM-free games. Most run using WINE

Old games packaged for win32, but extractable for the data files; most run using WINE