If you have installed a newer version of Debian GNU / Linux such as Debian Jessie or Debian 9 Stretch or Ubuntu 16 Xenial Xerus either on a server or on a personal Desktop laptop and you want tto execute a number of extra commands next to finalization of system boot just like we GNU / Linux users used to do already for the rest 25+ years you will be surprised that /etc/rc.local is no longer available (file is completely missing!!!).
This kind of behaviour (to avoid use of /etc/rc.local and make the file not present by default right after Linux OS install) was evident across many RedHack (Redhat) distributions such as Fedora and CentOS Linux for the last number of releases and the tendency was to also happen in Debian based distros too as it often does, however there was a possibility on this RPM based distros as well as rest of Linux distros to have the /etc/rc.local manually created to work around the missing file.
But NOoooo, the smart new generation GNU / Linux architects with large brains decided to completely wipe out the execution on Linux boot of /etc/rc.local from finalization stage, SMART isn't it??
For instance If you used to eat certain food for the last 25+ years and they suddenly prohibit you to eat it because they say this is not necessery anymore how would you feel?? Crazy isn't it??
Yes I understand the idea to wipe out /etc/rc.local did have a reason as the developers are striving to constanly improve the boot speed process (and the introduction of systemd(system and service manager) in Debian 8 Jessie over the past years did changed significantly on how Linux boots (earlier used SysV boot and LSB – linux standard based init scripts), but come on guys /etc/rc.local doesn't stone the boot process with minutes, including it will add just 2, 3 seconds extra to boot runtime, so why on earth did you decided to remove it??
What I really loved about Linux through the years was the high level of consistency and inter-operatibility, most things worked just the same way across distributions and there was some logic upgrade, but lately this kind of behaviour is changing so in many of the new things in both GUI and text mode (console) way to interact with a GNU / Linux PC all becomes messy sadly …
So the smart guys who develop Gnu / Linux distros said its time to depreciate /etc/rc.local to prevent the user to be able to execute his set of finalization commands at the end of each booted multiuser runlevel.
The good news is you can bring back (resurrect) /etc/rc.local really easy:
To so, just execute the following either in Physical /dev/tty Console or in Gnome-Terminal (for GNOME users) or for KDE GUI environment users in KDE's terminal emulator konsole:
cat <<EOF >/etc/rc.local
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
exit 0
EOF
chmod +x /etc/rc.local
systemctl start rc-local
systemctl status rc-local
I think above is self-explanatory /etc/rc.local file is being created and then to enable it we run systemctl start rc-local and then to check the just run rc-local service status systemctl status
To test /etc/rc.local is working as expected you can add to print any string on boot, right before exit 0 command in /etc/rc.local
you can add for example:
echo "YES, /etc/rc.local IS NOW AGAIN WORKING JUST LIKE IN EARLIER LINUX DISTRIBUTIONS!!! HOORAY !!!!";
On CentOS 7 and Fedora 18 codename (Spherical Cow) or other RPM based Linux distro if /etc/rc.local is missing you can follow very similar procedures to have it enabled, make sure
/etc/rc.d/rc.local
is existing
and /etc/rc.local is properly symlined to /etc/rc.d/rc.local
Also don't forget to check whether /etc/rc.d/rc.local is set to be executable file with ls -al /etc/rc.d/rc.local
If it is not executable, make it be by running cmd:
chmod a+x /etc/rc.d/rc.local
If file /etc/rc.d/rc.local happens to be missing just create it with following content:
#!/bin/sh
# Your boot time rc.commands goes somewhere below and above before exit 0
exit 0
That's all folks rc.local not working is solved, enjoy /etc/rc.local working again 🙂
Its probably not so common problem among new-comer Linux users / admins but sooner or later even those who haven't will cat by mistake (or on purpose) some binary file end result will be physical console / terminal / SSH Client (lets say PuTTY) will display some non-sense characters and whether typing you will type in some "alien language" characters this continues until you close up console and re-login. Of course its not such a big problem to re-login or (kill active SSH session).
But there is no sense to do that and loose time and most importantly loose your logged in session (especially if you have hopped to 4 ssh sessions and you forgot to run GNU / screen). Thus its handy to know about
# reset
command. Once issued in most cases TTY messed up characters gets fixed up. However if even reset doesn't fix it, there is another "hack" to resolve it with no need for relogin. This is an old hack from my old Linux days and not so popular among admins, here is how:
A bit outdated news but still worthy to mention as Debian GNU / Linux is important part of my life. On 16 of August this year Debian turned 20 years! I'm actively using Debian Linux for servers and Desktops over the past 13 years and for this time I've seen right before my eyes how debian grow and from buggy hobbyinst Linux distribution became a robust and rock-solid OS. Moreover Debian is now practically the most important Linux distribution around. Thanks to it currently a thousands of other world changing distributions like Ubuntu, Arch Linux, Knoppix Linux LiveCD, Linux Mint etc. Debian is truly multi platform as of time of writting supports 10 hardware architecture (platforms) – in this number Embedded devices like ARM processors, has translation of most shipped software to 73 languages and comes with about 20 000 installable software packages. Contribution of Debian GNU Linux for Free software community is immerse, hundreds of millions or even billion Debian servers or some kind of Debian based OSes are running all around the net. Besides that Debian is one of the largest if not the biggest and most influential Open Source Project. By its essence existing of Debian is just a miracle. Though out of date again, lets great each other with Happy Debian Anniversary and Wish Debian a many and healthy years of successful development!
I’ve used K3B just recently to RIP an Audio CD with music to MP3. K3b has done a great job ripping the tracks, the only problem was By default k3b RIPs songs in OGG Vorbis (.ogg) and not mp3. I personally prefer OGG Vorbis as it is a free freedom respecting audio format, however the problem was the .ogg-s cannot be read on many of the audio players and it could be a problem reading the RIPped oggs on Windows. I’ve done the RIP not for myself but for a Belarusian gfriend of mine and she is completely computer illiterate and if I pass her the songs in .OGG, there is no chance she succed in listening the oggs. I’ve seen later k3b has an option to choose to convert directly to MP3 Using linux mp3 lame library this however is time consuming and I have to wait another 10 minutes or so for the songs to be ripped to shorten the time I decided to directly convert the existing .ogg files to .mp3 on my (Debian Linux). There are probably many ways to convert .ogg to mp3 on linux and likely many GUI frontends (like SoundConverter) to use in graphic env.
I however am a console freak so I preferred doing it from terminal. I’ve done quick research on the net and figured out the good old ffmpeg is capable of converting .oggs to .mp3s. To convert all mp3s just ripped in the separate directory I had to run ffmpeg in a tiny bash loop.
A short bash shell script 1 liner combined with ffmpeg does it, e.g.;
for f in *.ogg; do ffmpeg -i "$f" "`basename "$f" .ogg`.mp3"; done.....
The loop example is in bash so in order to make the code work on FreeBSD it is necessery it is run in a bash shell and not in BSDs so common csh or tcsh.
Well, that’s all oggs are in mp3; Hip-hip Hooray 😉
At security critical hosts running Apache + PHP based sites it is recommended functions like:
system();
exec();shell_exec();.....
to be disabled. The reason is to mainly harden against script kiddies who might exploit your site/s and upload some shitty SK tool like PHP WebShell, PHP Shell and the probably thousands of “hacker” variations that exist nowdays.
In latest Debian stable Squeeze, suhosin – advanced protection module for php5 is being installed and enabled in Apache (by default). Simply disabling a number of functions using suhosin, could prevent multiple of future headaches and hours of pondering on who 0wn3d your server ….
Disabling the basic PHP system(); and other similar functions which allows shell spawn is not always possible, since some websites or CMS platforms depends on them for proper runnig, anyways whether it is possible disabling ’em is a must. There are two ways to disable system(); functions; One is through using /etc/php5/apache2/conf.d/suhosin.ini and 2nd by adding a list of functions that has to be disabled directly in Website Virtualhost file or in apache2.conf (/etc/apache2/apache2.conf; For people hosting multiple virtualhost websites on the same server using the custom domain Virtualhost method is probably better, since on a global scale the functions could be enabled if some of the websites hosted on the server requires exec(); to work OK. In any case using /etc/php5/apache2/conf.d/suhosin.ini to disable system(); functions in PHP is less messy …
1. Disabling PHP system(); fuctions through /etc/apache2/apache2.conf and custom site Vhosts
Place somewhere (I prefer near the end of config);;;
Disabling it for custom virtualhost is done by simply adding above Apache directvies (before the closing tag in /etc/apache2/sites-enabled/custom-vhost.com
2. Disabling PHP system();, exec(); shell spawn with suhosin.ini
By default there is no way to see what is inside a DJVU formatted document on both Windows and Linux OS platforms. It was just a few months ago I saw on one computer I had to fix up the DJVU format. DJVU format was developed for storing primary scanned documents which is rich in text and drawings. Many old and ancient documents for example Church books in latin and some older stuff is only to be found online in DJVU format. The main advantage of DJVU over lets say PDF which is also good for storing text and visual data is that DJVU's data encoding makes the files much more smaller in size, while still the quality of the scanned document is well readable for human eye.
DJVU is a file format alternative to PDF which we all know has been set itself to be one of the major standard formats for distributing electronic documents.
Besides old books there are plenty of old magazines, rare reports, tech reports newspapers from 1st and 2nd World War etc in DJVU. A typical DJVU document takes a size of only lets say 50 to 100 KBytes of size just for comparison most a typical PDF encoded document is approximately sized 500 KiloBytes.
1.% Reading DJVU's on M$ Windoze and Mac-s (WinDjView)
For Mac users there is also a port of WinDjView called MacDjView ;;;,
2.% Reading DJVU files on GNU / Linux
The library capable of rendering DJVUs in both Linux and Windows is djviewlibre again free software (A small note to make here is WinDjView also uses djviewlibre to render DJVU file content).
The program that is capable of viewing DJVU files in Linux is called djview4 I have so far tested it only with Debian GNU / Linux.
To add support to a desktop Debian GNU / Linux rel. (6.0.2) Squeeze, had to install following debs ;;;
pdf2djvu is not really necessery to install but I installed it since I think it is a good idea to have a PDF to DJVU converter on the system in case I somedays need it ;;;
djview4 is based on KDE's QT library, so unfortunately users like me who use GNOME for a desktop environment will have the QT library installed as a requirement of above apt-get ;;;
Here is Djview4 screenshot with one opened old times Bulgarian magazine called Computer – for you
Though the magazine opens fine, every now and then I got some spit errors whether scrolling the pages, but it could be due to improperly encoded DJVU file and not due to the reader. Pitily, whether I tried to maximize the PDF and read it in fullscreen I got (segfault) error and the program failed. Anyways at least I can read the magazine in non-fullscreen mode ;;; ,,,,
3.% Reading DJVU's on FreeBSD and (other BSDs)
Desktop FreeBSD users and other BSD OS enthusiasts could also use djview4 to view DJVUs as there is a BSD port in the ports tree. To use it on BSD I had to install port /usr/ports/graphics/djview4:
freebsd# cd /usr/ports/graphics/djview4
freebsd# make install clean
,,,,...
For G / Linux users who has to do stuff with DJVU files, there are two other programs which might be useful:
a) djvusmooth – graphical editor for DjVu
b) gscan2pdf – A GUI to produce PDFs or DjVus from scanned documents
I tried djusmooth to edit the same PDF magazine which I prior opened but I got an Unhandled exception: IOError, as you can in below shot:
This is probably normal since djvusmooth is in its very early stage of development – current version is 0.2.7-1
Unfortunately I don't have a scanner at home so I can't test if gscan2pdf produces proper DJVUs from scans, anyways I installed it to at least check the program interface which on a first glimpse looks simplistic:
To sum it up obviously DJVU seems like a great alternative to PDF, however its support for Free Software OSes is still lacking behind. The Current windows DJVU works way better, though hopefully this will change soon.
After writting in previous article on how talk be used to handle interactive chat console sessions on FreeBSD, I thought of dropping a few lines on how same is done on Debian, so here is how:
1.; Install talk and talkd
noah:/home/hipo# apt-get --yes install talk talkd
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
talk talkd
0 upgraded, 2 newly installed, 0 to remove and 93 not upgraded.
Need to get 19.0 kB/42.3 kB of archives.
After this operation, 201 kB of additional disk space will be used.
Get:1 http://ftp.nl.debian.org/debian/ stable/main talkd amd64 0.17-14 [19.0 kB]
Fetched 19.0 kB in 0s (67.1 kB/s)
Selecting previously deselected package talk.
(Reading database ... 90%
Unpacking talk (from .../talk_0.17-14_amd64.deb) ...
Selecting previously deselected package talkd.
Unpacking talkd (from .../talkd_0.17-14_amd64.deb) ...
Processing triggers for man-db ...
Setting up talk (0.17-14) ...
update-alternatives: using /usr/bin/netkit-ntalk to provide /usr/bin/talk (talk) in auto mode.
Setting up talkd (0.17-14) ...
2.;; Check and make sure talk and ntalkd lines are present in /etc/inetd.conf
Now you probably wonder why are there two lines in /etc/inetd.conf for ))
in.talkd and in.ntald
in.talkd daemon's aim is to deliver talk sessions between logged in users on one Linux host with few logged in users willing to talk to each other locally;; Wheter in.ntalkd is designed to serve interactive user talks between the host where in.ntalkd is installed and remote systems ruwhich have the talk client program installed. Of course in order for remote talks to work properly the firewall (if such has to be modified to allow in.ntalkd chats. I've never used in.ntalkd and on most machines having in.ntald hanging around from inetd, could be a potential security hole so, for people not planning to initiate remote TALKs between Unix / Linux / BSD hosts on a network it is a good practice the ntalkd line seen above in inetd.conf to be commented out ::;
3.;;; Restart openbsd-inetd init script and talk is ready to use
noah:~# /etc/init.d/openbsd-inetd restart
* Restarting internet superserver inetd
Onwards to use talk between two users the syntax is same like on other BSD, as a matter of fact TALK – console / terminal interactive chat originally was developed for the 4.2BSD UNIX release ;; the Linux code is a port of this BSD talk and not rewrite from scratch.
Using talk between two logged in users on pts/1 (lets say user test) and tty1 (user logged as root) is done with:
On tty1 the user has to have enabled Talk sessions request, by default this behaviour in Debian and probably other Debian based Linuxes (Ubuntu) for instance is configured to have talks disabled, i,e ,,,
root@noah:~# mesg
is n
Enabling it on root console is done with:
root@noah:~# mesg y
Once enabled the root will be able to see the TALK service requests on tty1 otherwise, the user gets nothing. With enabled messaging the root user will get on his tty:
Message from TalkDaemon@his_machine...
talk: connection requested by your_name@your_machine.
talk: respond with: talk your_name@your_machine
So on the root console to reply back to talk chat request:
Those who are in familiar with older UNIXes, UNIX BSD derivatives and GNU Linux should certainly remember the times, when we hackers used to talk to each other using talk service.
Those who don't know what talk command is it is a simple console / ssh utility to talk to another logged in users.
Talk is very similar to write and mesg one liner messasing utilities available for *nixes, the difference is it is intendted to provide interactive chat between the two logged in users. People who came to know UNIX or free software in older times most likely don't know talk, however I still remember how precious this tool was for communication back in the day.
I believe still it can be useful so I dediced to install ot on one FreeBSD host.
In order to have the talk service running on BSD it is necessery to have /usr/libexec/ntalkd installed on the system this however is installed by default with standard BSD OS installs, so no need for any external ports install to run it.
talk doesn't have it's own init script to start is not written to run as it own service but in order to run it is is necessery to enable it via inetd
Sys Admins managing QMAIL mail servers know, often it happens QMAIL queue gets filled with unwanted unsolicated SPAM e-mails due to a buggy WEB PHP / Perl mail sendingform or some other odd reason, like too many bouncing messages ,,,,
For one more time I’ve experienced the huge SPAM destined mails queue on one QMAIL running on Debian GNU / Linux.
= … Hence I needed to clean up the qmail queue. For this there is a little tool written in PERL called qmhandle
qmail-server:~# cd /usr/local/src qmail-server:/usr/local/src# wget -q https://www.pc-freak.net/files/qmhandle-1.3.2.tar.gz
B=) STOP QMAIL As it is written in the program documentation one has to be very careful when cleaning the mail queue. Be sure to stop qmail with qmailctl or whatever script is used to shutdown any mail sever in progress operations, otherwise there is big chance the queue to mess up badly .
C#) Check extended info about the mail queue:
qmail-server:/usr/local/src/qmhandle-1.3.2# ./qmhandle -l -c 102 (10, 10/102) Return-path: anonymous@qmail-hostname.com From: QMAIL-HOSTNAME To: as1riscl1.spun@gmail.com Subject: =?UTF8?B?QWNjb3VudCBpbmZvcm1hdGlvbiBmb3IgU09DQ0VSRkFNRQ==?= Date: 1 Sep 2011 21:02:16 -0000 Size: 581 bytes ,,,, 1136 (9, 9/1136) Return-path: werwer@qmail-hostname.com.tw From: martin.georgiev@qmail-hostname.com To: costador4312@ukr.net Subject: Link Exchange Proposal / Qmail-Hostname.com Date: Fri, 2 Sep 2011 07:58:52 +0100 (BST) Size: 1764 bytes ,,,,.... 1103 (22, 22/1103) Return-path: anonymous@qmail-hostname.com From: SOCCERFAME To: alex.masdf.e.kler.1@gmail.com Subject: =?UTF8?B?QWNjb3VudCBpbmZvcm1hdGlvbiBmb3IgU09DQ0VSRkFNRQ==?= Date: 2 Sep 2011 00:36:11 -0000 Size: 578 bytes ,,,,,, ,,,,.... Total messages: 1500 Messages with local recipients: 0 Messages with remote recipients: 1500 Messages with bounces: 500 Messages in preprocess: 300
D-) Delete the Queue qmail-server:/usr/local/src/qmhandle-1.3.2# ./qmHandle -D ...... ......
I know and I have enjoyed BB – Portable Demo for already a decade. I'm sure many newbies to the Free And Open Source (FOSS) realm don't know or heard of bb's existence as nowdays ASCII art is not so well known among youngsters. Hence this short post aims to raise some awareness of the existence of this already OLD but GOLD – awesome! text console / terminal demonstation BB 🙂
Historically bb used to be one of the main stunning things one could show to a fellow GNU / Linux new comer.
For the year 2000, seeing all this awesome ASCII video demo running on free Operating System like GNU / Linux was a big think. The fact that such an advanced ASCII art was distributed freely for an OS which used to exist since only (6 / 7 years) was really outstanding of its time.
I still remember how much I was amazed seeing a plain ascii video stream was possible only Linux. Moreover the minimal requirements of bb were quite low for its time – it worked on mostly all PCs one can find at the time.
BB's minimum requirements to work with no chops is just an old 486/66 DX2 CPU Mhz with few megas of memory (32MB of memory was more than enough to run it)
A very unique feature of bb was it was the first Linux demo that succesfully run simultaneously playing on two monitor screens as one can read on the project website. Unfortunately I didn't owned two monitors back in the day so never ever had the opportunity to see it running on two screens. Anyhow I've seen it runnign somewhere on some of the Linux install fests visited some years ago…
The demo was developed by 4 man group ppl – the AA group the same digital artists are also the guys behind the AA Project.
The main aim of AA-lib was to make possible (Doom, Second Reality, X windows) to run rendered in plain ASCII art text.
The project succeeded in a lot of his goals already as there is already existent such an ascii art ports of large games like QUAKE! Be sure to check this awesome project too AAquake ascii quake page is here , as well as video and pictures could be viewed under a plain console Linux tty or in terminal (via SSH 🙂 )
bb as well as aa-lib has ports for most modern Linux distros in that number one can easily get rpm or deb packages for most of distros. On Slackware Linux you should compile it from source. Though compilation should be a straightfoward process, not that i tried it myself but I remember a close friend of mine (a great Slackware devotee) who was the one to show me the demo for a first time on his Slackware box.
1. Installing bb on Debian Linux
Debian Linux users like me are privileged as for already many years a Debian package of bb is maintaned thanks to Uwe Herman
Hence for anyone willing to enjoy bb install it by running:
If you're running a X server the aa-lib will immediately run with its X server compiled support:
2. Installing BB demo on FreeBSD
On FreeBSD, bb demo has a port to install it run:
freebsd# cd /usr/ports/misc/bb freebsd# make install clean ...
Here is good time to say that even though in most of the machines, I've tested the demo I had on some of the hosts problems with sound due to buggy sound drivers. As of time of writting hopefully on most machines there will be no troubles as most of the Linux sb drivers are better supported by ALSA.
Everyone interested in both Free Software and ASCII art knows well how big in significance is the AA-lib project for the historical development and attraction for new hackers to the Linux dome. In that sense AAlib head developer Jan HubickaBy the way Jan Hubicka is also the author of another Linux tool called xaos. Xaos is a tool to deal with some kind of advanced higher mathematics stuff called fractals.
Unfortunately I don't know a bit for fractal maths and what the purpose of the tool is but as you can see on the shot it looks nice running 🙂
Here are also, lot of the major BB parts in shots:
For those on MS-Windows OS platform, here is the demo 🙂
BB ASCII Demo standard size running in Linux (With sound)
