Heavens Above! What You Can Learn about Software by Gazing at the Stars ...
I revisited the venerable astronomical program 'xephem' recently, and learnt some skills that I would like to pass on for their wider application under Linux.
Install 'xephem' on MX or Devuan Linux (if you have mislaid it between distro updates) by executing:
$ wget http://e2rd.piekielko.pl/debian/binary-amd64/xephem_3.7.7-4_amd64.deb
$ wget http://e2rd.piekielko.pl/debian/binary-amd64/xephem-catalogs_0.0.20161106-1_all.deb
# apt install libmotif
# apt install libxm4
# dpkg -i xephem_3.7.7-4_amd64.deb
# dpkg -i xephem-catalogs_0.0.20161106-1_all.deb
$ xephem
I aimed to automatically generate a 2-dimensional plot from the output of 'xephem', showing the direction of each star and how high in the sky it is. The output from 'xephem' at a given time and place includes the azimuth (bearing from north) and altitude (angle up from horizontal) to each astro-body of interest. I convert these numbers into a point on a 2-dimensional graph, a line from the origin to that point showing the body direction, and the length of line proportional to the angle up to the body.
>>> Useful skill number 1 ... the korn shell <<<
There are simple trigonometrical equations for calculating these plotted star positions. Unfortunately, the bourne-again shell has no native maths functions, thus forcing use of external functions such as 'bc -l', with its limited trigonometric expressions. The programming is messy to read and so hard to debug. On the other hand, the korn shell has all the native maths functions you could reasonably want. The equations are written in exactly the way they occur in normal algebra -- easy to read and debug. So I adopted 'ksh' instead of 'bash' for this whole project.
>>> Useful skill number 2 ... the gnuplot program <<<
I chose the powerful 'gnuplot' program for plotting the positions thus calculated. Start gnuplot by typing "gnuplot", and then execute a heuristic sequence of gnuplot commands; when happy with them, put them in a file that can be automatically run by gnuplot. I want the plot to comprise the star positions, along with their names and directions. It turns out that I can kill two birds with one stone right here. In gnuplot there are two commands: "plot ... with labels", which writes the text that is next to the position in the data file, and "plot ... with lines" which draws a straight line between successive data points in the file.
So I put (only some shown) the star x,y coordinates in the file "plot.xy" like this:
44 25 Spica
21 -6 Antares
-26 -25 Canopus
-14 37 Regulus
and I insert a line with just '0 0' in it before every data line, using this script:
rm -f plot.dat
(while read line
do
echo "0 0" >> plot.dat
echo "$line" >> plot.dat
done ) < plot.xy
which produces the new file "plot.dat" which looks like this:
0 0
44 25 Spica
0 0
21 -6 Antares
0 0
-26 -25 Canopus
0 0
-14 37 Regulus
Now, if I start gnuplot and run the command "plot 'plot.dat' with labels" I get the text "Spica" centered on the point (44,25), no text at (0,0), the text "Antares" around the point (21,-6), etc, shown here with labels. However, if I run the command "plot 'plot.dat' with lines" I get a straight line from (0,0) out to (44,25), then a straight line back to (0,0), then a straight line out to (21,-6), and so on, which produces direction lines from me (the observer at (0,0)) to every star position, shown here with lines. These are distinct plots. To get the "lines" plot on top of the "labels" plot, you add the extra " 'plot.dat' with lines" to the 'plot' command; this shows the final result.
>>> Useful skill number 3 ... /bin/date -d <<<
I ultimately want a printable star chart. In gnuplot you can specify that the output goes to pdf by the command "set term pdf size 7,7" (giving a 7 inch x 7inch area on an A4 page for the plot) followed by the command "set output 'plot.pdf'" (to define the output filename). Note that the date-stamp of the observations produced by 'xephem' (4/2/2023) is not very descriptive; if I want it in the title of the plot it needs a bit of massaging. The '/bin/date' program, run as '/bin/date -d "4/2/2023"', gives me the more useful form 'Sun 2 Apr 2023' instead. To get a title on the plot, use the command "set title '22:45 Sun 2 Apr 2023'".
The interactive gnuplot commands so far look like this:
$ gnuplot
gnuplot> set term pdf size 7,7
gnuplot> set output 'plot.pdf'
gnuplot> set title "22:45 Sun 2 Apr 2023"
gnuplot> plot 'plot.dat' with labels, 'plot.dat' with lines
gnuplot> quit
and if these commands (to the right of each '>' prompt) are written to a file called 'gnuplot.in', the whole lot can be executed automatically by running: "gnuplot gnuplot.in". Instead of printing it with 'lpr plot.pdf', I just display the 'plot.pdf' on the computer (using 'xpdf' or 'evince'), photograph it on my phone, and take that outside to identify everything in the sky. I have included that star plot here produced by this system.
There are advanced configuration options available to all of these programs; I have been able to survive on their simplest defaults.
Having Way Too Much Fun with an old NEC Powermate P6050 Desktop Computer
This item came into my possession recently -- it was born in 2009, according to the BIOS, and looks like my old, dead iMac, which is why I got very interested.
Power up, press F2 for the BIOS, shove in Knoppix 7.2 on DVD, see what the hardware is.
Nice. It has an Atheros wireless chipset, a traditional BIOS, built-in speakers, and can boot from CDROM. So it is clearly time to rip off the Windows sticker and install Devuan 'ascii'.
The installation goes without a hitch, and I reboot into Devuan. Something flashes across the screen too fast to read. What is it? I take a movie and discover it is just an old-fashioned BIOS message, "copyright 1984-2007 phoenix technologies ltd" etc. But why does that not stay on the screen a bit longer?
The booting continues OK, and I browse the web for an answer to the BIOS message problem, but now I am told that ordinary sites are suddenly dangerous to continue with, because of out-of-date certificates! Clearly a clock problem, from my previous experience. And indeed, the date has reverted to 1 Jan 2009.
So the CMOS battery needs replacing. I do it, after noting how the existing battery was installed. That battery only had 0.04 Volts left in it.
Power up and reboot into the BIOS, set the correct date, and reboot: the date is now OK. Power down for the day. But the next day, power up and boot ... and the date is back to 2009! WTF!?
... Is the CMOS battery around the wrong way? I open it up and decide to reverse the CMOS battery, which I had replaced the same way around as the one that was in there already, but if that was back-to-front then this is worth trying. Rebooted and it now holds the correct CMOS date. Phew!
I then examined the output of 'dmesg' and found lines like this one:
ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Pm1aEventBlock: 32/8 (20160831/tbfadt-603) [etc]
which the web suggested was due to it being in an old format, not expected by a modern linux kernel. After all, the Phoenix BIOS was made in 2007, this NEC in 2009, and it is 2019 already.
Suggested fixes on the 'web to some seemingly-random problems that might arise from this were: in /etc/default/grub, change the relevant line
to ---> GRUB_CMDLINE_LINUX_DEFAULT="noapic nolapic"
or to ---> GRUB_CMDLINE_LINUX_DEFAULT="acpi=off"
With nothing to lose, I tried both and the first worked better. I also altered some BIOS options so I could see the Phoenix notice for a few seconds. I set:
no exec page protect ---> enable
speed step ---> disable
silent boot ---> disable
media instant ---> disable
power off usb ---> disable
I turned off the power and went to bed. The next day it all booted normally.
And so far it remains totally tamed --- and I love it!
Learning Stuff from the Korn Shell Documentation
I have been using the Korn Shell on OpenBSD recently, and being forced to consult some excellent resources on it, have come across some things I did not know, that I can apply to the Bourne Again Shell when I get back to Devuan Linux.
One mistake that bit me for a few puzzling hours was the 'read' function used within a 'while read line do' loop.
Here is the failed script portion:
(while read line
do
subject=$(echo $line|awk -F / '{print $1}')
movie=$(echo $line|awk -F / '{print $2}')
echo -n "ENTER ($subject) or q=quit < "
read ans
[ "$ans" == "q" ] && exit 0
mpv $movie
done)<play-order
Very amusing. It took about three hours to eventually dawn on me that the 'read ans' command within the brackets READS FROM THE SAME STREAM as the file 'play-order', and thus never reads the actual response typed in from the keyboard.
Barry Rosenberg's book 'Hands-On KornShell93 Programming', full of engaging examples, gives me the commands
exec 3< play-order
to open an input stream from the file 'play-order' using file ID '3', and then the command
read -u0 ans
to get the typed-in response 'ans' from the keyboard.
Here is the working script portion:
exec 3< play-order
while read -u3 line
do
subject=$(echo $line|awk -F / '{print $1}')
movie=$(echo $line|awk -F / '{print $2}')
echo -n "ENTER ($subject) or q=quit < "
read -u0 ans
[ "$ans" == "q" ] && exit 0
mpv $movie
done
Straightforward. No more confusion. No extra process. Variables recognised script-wide. Simplicity. Easily debugged. All the good things.
So I now program to the 'ksh' standard from the start, knowing that the resulting script will run on OpenBSD (under ksh) and on Linux (under bash) without modification.
The ENCRYPT Act Protects Encryption from State Prying
Not a headline that we in Australia are likely to see any time soon; it comes from the U.S. And for the record, I quote the article here, which is by the Electronic Freedom Foundation.
The ENCRYPT Act Protects Encryption from U.S. State Prying
It’s not just the Department of Justice and the FBI that want to undermine your right to private communications and secure devices—some state lawmakers want to weaken encryption, too. In recent years, a couple of state legislatures introduced bills to restrict or outright ban encryption on smartphones and other devices. Fortunately, several Congress members recently introduced their own bill to stop this dangerous trend before it goes any further.
The bill is called the ENCRYPT Act. EFF gladly supports it and thanks Representatives Ted Lieu (D-CA), Mike Bishop (R-MI), Suzan DelBene (D-WA), and Jim Jordan (R-OH) for sponsoring and co-sponsoring the bill.
Encryption—the technology used to secure data on phones and computers and keep digital messages safe from eavesdroppers—is under threat around the world. In the U.S., some of those threats have come from the Department of Justice and FBI, which want technology companies to purposefully and irresponsibly weaken encryption so that law enforcement can more easily get their hands on the contents of encrypted data and messages.
But the threats have come from individual U.S. states, too.
Two years ago, lawmakers in California and New York introduced statewide legislation that would’ve significantly limited their residents’ access to encrypted devices and services. In California, for example, Assembly Bill 1681 would have originally required that any smartphone sold in the state be “capable of being decrypted and unlocked by its manufacturer or its operating system provider.” To help compel this, manufacturers could have been subject to fines of $2,500 for every non-compliant device sold in the state.
This piecemeal approach to encryption is not just wrong-headed, it simply won’t work. If state legislatures individually meddle with encryption policy, we could see a landscape where Illinois residents can buy the latest iPhone and download messaging apps like Signal and WhatsApp, but Californians can’t. But the California and New York state bills, intended to help law enforcement catch criminals, ignored the reality that people could still cross into states where the technology is unrestricted to purchase encrypted devices. What’s more, it would be trivially easy for anyone to download encrypted messaging apps online, regardless of state laws.
The ENCRYPT Act would make sure this scenario doesn’t come to pass. In fact, the bill was originally introduced in 2016 as a bulwark against the California and New York state bills—both of which failed on their own.
The ENCRYPT Act would prevent U.S. states and local governments from compelling companies to weaken their encrypted products or store decryption keys for use on demand by law enforcement. It would also prevent states from prohibiting the sale and offering of certain devices and services based solely on their encryption capabilities. That means everyone across the United States, no matter what state they live in, could have equal access to strong encryption.
Of course, there are threats to encryption at the federal level as well, which is why EFF also [110]supports the Secure Data Act. The Secure Data Act, which also has bipartisan sponsorship, would act as a perfect complement to the ENCRYPT Act by prohibiting courts and federal agencies from mandating weakened encryption or otherwise intentionally introducing security vulnerabilities. Together, the two bills would go a long way toward ensuring that strong encryption remains free of government interference in the United States.
In the meantime, the ENCRYPT Act gets encryption policy right. Your zip
code shouldn't determine your digital security.
The Linux Supporters Group Software Packages
Security software for ordinary users can be overly-complex. Even a graphical interface can be daunting to navigate, if the underlying principle of operation of the software is convoluted.
Here at the LSGA we consider 'gpg' too confusing for beginners' use. This has been borne out by many years of independant research. You also need to appreciate that in the long term it is vulnerable to a breakthrough in the algorithm for factoring large numbers into primes. We do not do GUIs. We develop simple commandline interfaces for a restricted set of practical requirements. If your requirements match, you can use the program.
For example, we have 'lsga-secure' for protecting a set of files and folders on your PC using AES via the LibreSSL program.
For example, we are developing 'lsga-private' for sending a one-time encrypted file to another person, avoiding the gpg system.
In all cases, we aim at: simple installation as a normal user (not root); simple commands, at most two words; fail-safe operation (everything anticipated).
The so-called Next Unit of Computing comprises a range of small-form-factor personal computers designed by Intel.
The BOX-NUC-7i3-BNK kit was lying around at the computer shop I was in, noticed whilst I was seeking something similar. Made a few months ago, it is a seventh generation Kaby Lake-U i3-Core system in a box about 4 inches square and an inch high, perfect for portable and headless operation.
I stuck 4GB of RAM into it, along with a 250GB SSD --- and installed Devuan 2.0 ASCII, which proceeded happily, uneventfully and successfully.
The wireless NIC (an Intel Dual Band Wireless AC 8265) was useable straight away, as was the ethernet. There shall be more on this later as I explore this device further.
This device appeared at our Linux Learners Lounge recently. I stuck it into a Samsung notebook on which we had just installed Mint 18.3 ... and waited ... but could not detect evidence that it was working.
Why not?
Because I'm so old fashioned -- I have not dealt with these creatures since the Optus E160/E1762 USB dongle. In those days it was clear to us. They were detected after being plugged in to the USB port; devices at /dev/ttyUSB0 and /dev/ttyUSB1 created; their mode switched, configured as a serial modem, run by the point-to-point daemon; and the ppp0 interface created to manage connections.
Nothing at all like that happened. Complete silence, from my point of view. No 'mobile-broadband' entry in the network manager, either.
I was quite stuck for inspiration.
Trusting Knoppix to deal with most hardware, I booted Knoppix 8.1 on a Lenovo laptop, and stuck in the dongle. It was seen by 'dmesg'. But the really weird thing was that the interface 'eth0' was created, even though this laptop has no ethernet NIC.
Did this come from the dongle? An IP address was handed out, too, at 192.168.1.100, and 'ping' saw linuxlsga.net and browsing worked! /sbin/route showed eth0 as the only way out, so it doesn't create /dev/ttyUSB0 or ppp0. So which program was handling the connection? 'ps ax' returned 'dhclient'. All so odd to me.
OK. Try one more computer ... Devuan 2.0 on a Macbook with eth0 and wlan0 NICs.
Boot; insert; eth1 created. But this time I had wicd in control, not network-manager. And there, amongst the other wireless-access points, was one I had not seen before at home, but that had been present at the Lounge: named like TWD4G_ABC. I clicked on 'connect' --- and it said:
This device needs a WPA2 encryption key (!)
Oh, well ... RTFM. Onto another computer, internet, download the manual, which explains that a 'wingle' is a 'dongle' with the added ability to be connected by wifi from other computers. It suggests pulling off the cover of the dongle, which reveals ... the SSID (like TWD4G_ABC) and the WPA2 key (like 98543322).
So ... typed in the number, clicked connect, and ... it associated, authenticated, and got an IP address (192.168.1.100), but this time it created the interface 'wlan0' instead. And now 'ps ax' showed that 'wpa_supplicant' was running the session. Aha!
It all worked perfectly! Despite the three distros slightly different methods, the procedure is straightforward. And at last I understood that the older method of treating it like a dial-up modem has now been replaced by the newer method of treating it as a wireless access point.
Both have their logic ... but a 'wingle' ain't a 'dongle'. Old habits die hard, but I am now one happy chappy again!
It is mid-June, 2018, and I am happily typing the command:
$ lsb_release -a
into my laptop and receiving the surprising response:
Distributor ID: Devuan
Description: Devuan GNU/Linux 2.0 (ascii)
Release: 2.0
Codename: ascii
I have decided, after 20 years with Debian, to switch all my computer systems to Devuan GNU+Linux, thus abandoning Debian New/Linux completely.
Why?
This line greeted me a week ago at the start of an email:
"Dear Init Freedom Lovers: Once again the Veteran Unix Admins salute you!"
Of course, I was intrigued. I had long ago subscribed to the Devuan announcements, but without much hope, just keeping abreast of things.
But this time was different. Version 2.0 was ready for download! Version 2.0 already!
Up until then, I had just noticed some straws in the wind, in both Jessie and Stretch: the sudden disappearance of "CTRL+ALT+BKSP" as default to kill the X Server; the loss of "/etc/rc.local" as default for your own post-boot commands; the weird failure as default to name single interfaces "eth0" and "wlan0"; the occasional and inexplicable lockups; and most recently, the strange 3 minute wait when my "/etc/network/interfaces" entry was ignored.
This reminded me of what the young Bob Dylan once sang: "A lot of people don't have much food on their table -- But they got a lot of forks and knives -- And they gotta cut something ..."
None-the-less, these niggles did not add up to action on my part, until a day after that email. I was tidying up, and found an old book (published in 2008) called "Linux in Easy Steps" by Mike McGrath. I re-read it, and as I did so, it made me see the Linux landscape freshly for the first time in ages.
So I opened another one of my old books (published in 2001): "Debian GNU/Linux Bible" by Steve Hunger, and re-discovered Ian Murdock's foreword ...
As I read, there were other things that I realised we had lost bit by bit: - "Run levels obsolete ..."; - "CTRL+ALT+F1-6" not always enabled in many distros; - (etc). And a certain nostalgia for those good old days started to well up inside me.
So I suddenly thought: F**k It! --- I owe it to them to try it out.
And I did. On three computers: an old BIOS and two UEFI.
Devuan installed in a straight-forward way (even though the questions seemed slightly unusual and a little unfamiliar to a debian guy).
And when I booted Devuan and played with it, I felt that I could breath again ... Fast. Solid. /etc/rc2.d and friends. Sane defaults. Backward-compatible. All the things we always took for-granted. Lots of little things came flooding back.
And it turns out that for those of us fortunate enough to have jettisoned Gnome on the first whiff of Gnome3, we now have our reward: migrating from both Debian Jessie and Debian Stretch to Devuan ASCII is without drama!
I decided to risk this migration on my main UEFI computer.
There were two delightful 'gotchas' which were easily circumvented.
First: not enough space for the upgrade. Fixed by making a soft link for /var/cache/apt on an external USB stick.
Second: all my openssl-encrypted files would not decrypt. Fixed by some RTFM, i.e., the message digest default changed from md5 to sha256 after the upgrade.
Finally, there was a small glitch whilst configuring the init scripts, which was solved by removing the file /etc/init.d/runmbbservice, and then it all worked.
I ran this at the end of the procedure:
$ pidof systemd
$ /bin/ls -l /sbin/init
-rwxr-xr-x 1 root root 37064 Jun 15 2017 /sbin/init
$ pidof init
1
But there shall be more to come later, after I familiarise myself with this thing.
And ... Veteran Unix Admins: I salute you!
I was well and truly pinged by RTFM today!
Adding a postinst to a .deb package, I wrote a 'here document':
cat << EOF > postinst
#!/bin/bash
[ -z "$(which gpg)" ] && su -c "apt-get install gnupg"
exit 0
EOF
But it simply would not work.
What I wanted was:
[ -z "$(which gpg)" ] && su -c "apt-get install gnupg"
but what I got was the interpretation on this computer (which already had gpg):
[ -z /usr/bin/gpg ] && su -c "apt-get install gnupg"
whereas the other computer, where the .deb was installed, had no gpg but this statement always thinks it has!
Eventually, I twigged to it. I first tried the reasonable kludge (\$):
cat << EOF > postinst
#!/bin/bash
[ -z "\$(which gpg)" ] && su -c "apt-get install gnupg"
exit 0
EOF
which worked, but later, after exploring the 'net (and, as a last resort, 'RTFM bash'), I got it (single quotes around the delimiter inhibit the expression expansion):
cat << 'EOF' > postinst
#!/bin/bash
[ -z "$(which gpg)" ] && su -c "apt-get install gnupg"
exit 0
EOF
which finally gives the required:
#!/bin/bash
[ -z "$(which gpg)" ] && su -c "apt-get install gnupg"
exit 0
Beautiful!
Just for fun, I tried booting Tails (The Amnesic Incognito Live System) on my HP-Stream-11.
Very informative.
I download the .iso for Tails-2.12 and dd it onto a USB stick.
It fails to boot --- of course.
RTFM: https://tails.boum.org/install/expert/usb/index.en.html
You need to use the tails-installer to properly format and copy this.
$ lsb_release -a
Distributor ID: Debian
Description: Debian GNU/Linux 9.0 (stretch)
Release: 9.0
Codename: stretch
# apt-get install tails-installer
No! You are meant to use the jessie backports ... Done.
And then where is it?
# tails-installer
bash: tails-installer: command not found
# which tails-installer
# find / -type f -name tails-installer
/usr/lib/tails_installer/tails-installer
So it is hiding; in fact hiding in the menu:
Applications
-->System
-->Tails Installer
OK. Click on it. Supply a USB stick with no partitions, all free space. Fine.
Then boot the USB in the HP-Stream, expecting to provide the Intel 3165 Wireless chip microcode on a separate USB stick ...
Imagine my suprise when it recognises the chip and all the wireless networks and connects straight away via WPA2.
Thus I have to REMEMBER that TND ('Tails is not Debian'), so it has all the non-free stuff in it already.
After that, no surprises ... except for the searches.
Search for linuxlsga.net using Google.
"Our systems have detected unusual traffic from your computer network.
Please try your request again later ..."
"This page appears when Google automatically detects requests coming from your computer network which appear to be in violation of the Terms of Service."
There are barely-tolerable reasons for this.
So --> Search for linuxlsga.net using DuckDuckGo.
Straight there.
Upgraded my search engine in my Firefox ...
We'll do a bit on Tails at our monthly meeting later this year.
Very informative!
I got a cheap $A200 HP Stream Notebook, manufactured after April 2016, that had been returned for some reason, and installed Mint 18 on it for our U3A Course Workshop. It has storeage of 32GB SSD (flash/eMMC), 2GB ram, and a wireless-only network interface.
That worked fine.
However, I also wanted to try out Debian 9 'Stretch', which is in testing at present, so I installed that alongside Mint.
Wow! That was a little frustrating! But Debian aficionados have an amazingly high tolerance of frustration -- otherwise we'd just use Mint and be done with it!
The problem is this: the Stream only has a wireless network interface, not a wired one, and it is unsupported by free software in Debian terms, so the installer asks you to provide it separately later on.
This is a tricky -- and undocumented in detail -- procedure. I have encountered this situation before and I have failed every time to get it to work. Many others on the web report just this failure as well. It took me a couple of lazy days, but I discovered a reliable procedure in the Debian bug blogs!
Let's go!
First, prepare the UEFI:
power on
spam esc key
f10 into bios
across to system configuration
down to boot options
....legacy support disabled
....secure boot disabled
....clear all secure boot keys
down to uefi boot order
....os boot manager
....usb diskette on key/usb hard disk
save and exit
Then I chose a version of Debian 9 'Stretch', kernel 4.9.0:
debian-testing-amd64-xfce-CD-1.iso
from
http://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/
and shoved it on a USB stick like this:
# dd if=debian-testing-amd64-xfce-CD-1.iso of=/dev/sdb bs=1M; sync
and obtained the extra wireless firmware:
firmware-iwlwifi_20161130-2_all.deb
from
https://packages.debian.org/uk/sid/all/firmware-iwlwifi/download
I found that the bug blogs at:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740503
report that it seems check-missing-firmware does not work with a USB drive that contains a partition table, so to be on the safe side in future they
recommend a basic FAT filesystem on a partitionless USB stick to hold the firmware package, thus:
# cfdisk /dev/sdc (delete all partitions so it is all free space)
# mkfs.vfat -I /dev/sdc (for -I switch see manual for mkfs.vfat)
# mount -t vfat /dev/sdc /mnt/
# cp firmware-iwlwifi_20161130-2_all.deb /mnt/
# umount /dev/sdc
Now insert the USB containing debian-testing-amd64-xfce-CD-1.iso
power on
spam the 'esc' key
Startup Menu appears
select and press 'F9 Boot Device Options'
scroll down to
....USB Hard Drive (UEFI) - USB Disk 2.0
select: press ENTER
get Debian splash screen
....Debian GNU/Linux testing
....Debian GNU/Linux UEFI Installation menu
scroll down to Install and press ENTER
determine language, time zone, keymap.
When it comes to configuring the network, the installer asks for extra files on USB; lucky that the Stream has two USB ports!
"Some of your hardware needs non-free firmware files to operate."
"The missing firmware files are:"
"iwlwifi-7265D-17.ucode iwlwifi-7265D-18.ucode iwlwifi-7265D-19.ucode iwlwifi-7265D-20.ucode iwlwifi-7265D-21.ucode iwlwifi-7265D-22.ucode iwlwifi-7265D-23.ucode iwlwifi-7265D-24.ucode iwlwifi-7265D-25.ucode iwlwifi-7265D-26.ucode"
"Load missing firmware from removeable media?"
Insert USB stick containing firmware.
Wait until light on stick stops flashing
YES
Press ENTER
Five seconds later the installer comes back and asks again for this subset:
"iwlwifi-7265D-23.ucode iwlwifi-7265D-24.ucode iwlwifi-7265D-25.ucode iwlwifi-7265D-26.ucode"
"Load missing firmware from removeable media?"
YES (ENTER)
Another nail-biting ten seconds ... and ...
Select the wireless network to use during the installation process
Select security of WPA/WPA2 PSK
Enter passphrase for WPA authentication
"Network autoconfiguration has succeeded!"
... and you are up and running!
The rest is uneventful, except to note that during the manual partitioning, we select and tell Debian to use the existing EFI System Partition on the SSD.
By the way, after you boot Stretch, you shall look in vain for /sbin/ifconfig because it ain't there. This is Debian's way of persuading you to learn the ip suite of programs. If, like me, you are not quite ready for that, just run # apt-get install net-tools.
Great!
Our group is conducting a public course: 'Learn Linux: Intro. to Linux' at the Digital Hub in Adelaide during September. As part of it we demonstrate a suitable Linux distro. to the participants. Normally that would be the most popular one, Linux Mint.
The latest and 'greatest' is Linux Mint 18 (codename 'Sarah'), but because you cannot imagine it, we shall describe our surprise when we tried it out like a newbie (which it is aimed at).
Grab the 64-bit (UEFI-enabled) 'Cinnamon' flavour, which boots OK [F12] from USB on the ACER Aspire e3-112 laptop. Delicate music. Elegant desktop. Nice. So let's road test it. Insert USB stick. Play a movie.
... Utter silence --- utter darkness --- no codecs, it seems.
Oh, dear! Linux Mint 17 never did this! At least we have the internet and a whole lot of experience; but what would a newbie make of this failure in a 'user-friendly' distro?
Suppose I am clairvoyant, and discover Menu -> Sound and Video -> Install Multimedia Codecs?
Right. It gets half way through and then emits an unintelligible raft of error messages:
"Could not download all respository indexes ... Data from such a repository can't be authenticated and is therefore potentially dangerous to use ... [etc.]"
It gets worse. If I idly click on the Bluetooth icon, a window comes up asking:
"Do you want to download mint-meta-codecs?"
and if I say 'yes', 5 minutes of download ends with the cryptic:
"An error occurred. W: Can't drop privileges for downloading as file ... Permission denied"
WTF?
So: scour the web ... Aaagh! Just as any newbie could figure out, we 'get up a terminal' and type:
$ sudo apt-get install mint-meta-codecs
and download another 124 unfamiliar packages ... and what happens?
"E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing"
This is pretty well gibberish to a novice, even though it eventually works if the advice is followed properly.
Such a strange and avoidable regression! Mint used to work out of the box; now this behaviour deliberately cripples it in a way that is designed to puzzle, irritate and possibly repel newbies by the barrelful; --- windows 10 anyone? ... macOSX? ... puppy?
I chose the Debian 8.5 Jessie amd64 net-installer (4th June 2016), which understands and includes configuration for the EFI protocol.
I booted the laptop, and using the F12 key entered the BIOS to enable booting from a USB stick as the first option, which it did OK. The Debian splash screen explicitly stated that it was the EFI version of the net installer.
The network installation went OK. I booted into the new system when it asked, and ... it went straight to windows-10!
Some web-scouring alerted me to the fact that I should have created a separate partition on which to place the EFI stanzas. So I installed again, this time noticing that there actually was a small partion labelled 'ESP', which I found out means 'EFI System Partition'. I told Debian to use it for the EFI configuration.
OK. Reboot. Straight to windows-10 again!
There are two drives on this laptop. Perhaps I chose the EFI partition of the wrong one, or more likely it is not booting from the one I chose. So I shut down windows-10 and restarted it, pressing the F12 key to enter the BIOS ... straight past the BIOS into windows-10! Again!
More web-based research revealed that windows-10 uses 'fast-boot' in these circumstances, by-passing the BIOS checks. So I pressed the power button for a long time, until the laptop was really off, then started a cold boot, pressed F12 ... and got into the BIOS at last!
I altered the boot order so that my choice of drive booted before the other drive, exited the BIOS, and ... got the Debian Jessie splash screen, with the full normal Debian menu, including the windows boot manager entry, all good to go --- which it did!
Later on I came across this excellent tutorial on linux and uefi which would have been quite helpful at the time.
All in all, I learnt a couple of things ...
So here I am using the 2016-02-26-raspbian-jessie-lite.img, precisely because I do not need a GUI.
The only annoying thing about the RPi is that it insists on booting up through the HDMI, with all its attendant paraphernalia, instead of through the ethernet port. At least you only ever have to do that once, and then run '# raspi-config', but it is still a pest. So I eventually found this solution:
http://raspberrypi.stackexchange.com/questions/13137/how-can-i-mount-a-raspberry-pi-linux-distro-image
which is truly wonderful. Herewith, the better method:
(1). Examine the image as a block device:
# /sbin/cfdisk 2016-02-26-raspbian-jessie-lite.img
Device - - - - - - - - - - - - - - - Start -- End - Sectors - Type
Free space . . . . . . . . . . . . . 002048 0008191 0006144
2016-02-26-raspbian-jessie-lite.img1 008192 0131071 0122880 W95 FAT32 (LBA)
2016-02-26-raspbian-jessie-lite.img2 131072 2658303 2527232 Linux
(2). Calculate the offset in bytes by multiplying this unit size by where the partition starts:
1st partition 512 * 8192 = 4194304
2nd partition 512 * 131072 = 67108864
(3). Mount these two partitions using the offset option of the mount command:
# mkdir -p image/one image/two
# mount -v -o offset=4194304 -t vfat 2016-02-26-raspbian-jessie-lite.img image/one
# mount -v -o offset=67108864 -t ext4 2016-02-26-raspbian-jessie-lite.img image/two
# /bin/ls -F image/two
bin/ boot/ dev/ etc/ home/ lib/ lost+found/ media/ mnt/ opt/ proc/ root/ run/ sbin/ srv/ sys/ tmp/ usr/ var/
Well, well, well ... And as it is mounted read/write, you can just alter it in situ. Let's do that now.
(4). Establish an initial ethernet configuration:
# vi image/two/etc/network/interfaces
and replace the line:
iface eth0 inet manual
with these lines:
auto eth0
iface eth0 inet static
address 192.168.1.1
netmask 255.255.255.0
(5). Commit this change to the image:
# umount image/one
# umount image/two
(6). Write this modified image to an SD card, insert the card into the RasPi-3B and boot; and lo! You'll find that you can immediately log in through the ethernet port by '$ ssh pi@192.168.1.1' in the usual way, then execute '$ sudo su', and complete your configuration using '# raspi-config'.
Of course, if you want to make a DHCP service available via your laptop when the pi boots, then you could install isc-dhcp-server on the laptop, configure it appropriately, and put the line "iface eth0 inet dhcp" into /etc/network/interfaces on the pi instead. Connecting the pi to a switch which is in turn connected to a modem-router achieves the same result. But I won't go into that here.
The good thing is having the integrated wireless capability. However, my initial experience is that it is flaky, and the blogs suggest executing '# /sbin/iwconfig wlan0 power off' which seems to pretty much cure it. Maybe I should just use a heftier power supply ...
There have been reports of a new largest known prime number, 2^74207281-1, which is >22 million digits.
Noting that '$ man dc' says dc - an arbitrary precision calculator, I decided, for some idle fun, to calculate this prime number on the new Raspberry Pi 3 Model B --- a 64-bit 1.2GHz quad-core ARMv7 or ARMv8 Processor rev 4 (v7l) running at 38 or 76 BogoMIPS (all this depending on whether you believe the manufacturer's spec., test data, or what is reported by '$ cat /proc/cpuinfo' and '$ dmesg'!). Thus:
$ time nice -20 echo "2 74207281 ^ 1 - p"|dc
300376418084606182 ... [followed by more than 22 million digits] ... 010073391086436351
real 211m36.767s
which is the correct new largest known prime number.
The same calculation takes 42m on my 3.60GHz tower, so this is not bad going for a humble pi ...
We'll look at the Model 3/B in more detail soon at one of our monthly meetings.
Too much attention on GNU/Linux distros, not enough on mobile derivatives. But eventually you get sick of the lack of security support for your [expletive deleted] [phone model suppressed] and get pushed over the edge by the StageFright vulnerabilities.
Makers of my old 'smart' phone fail to push fixes for months, and there is no backporting. I understand why, but it is simply unacceptable. Driven to desperation, I looked for a recent phone on which I could install security fixes promptly. The one I chose is on special for AU$239 and is the Moto G 2014 model XT1068.
Motorola provides an unlocking procedure, which works fine. Debian provides fastboot and android debugging support for rooting the device. The CyanogenMod community provides CM-12 and CM-13 for this phone, which installs flawlessly (GPS fix extra). Nightly builds are available. StageFright banished. Etc.
What is there not to like about the user interface? The only issues might be with Java Runtime Environment security. Next Feb 2016 we present a detailed talk about all this.
Wow!
Beautiful little machine for only AUD$299. It comes with Windows 8.1 + UEFI + secure boot. Nobody in the world needs Windows 8.1, and we'll see about the other two features. The blogs report some difficulty installing --- even failure. So here goes!
Boot while pressing F2 to enter setup, and configure these items:
-> Main -> F12 boot menu [Enabled]
-> Security -> Set administration password
-> Boot
----> Boot Mode [Legacy]
----> Secure Boot [Disabled]
-> Exit Saving Changes
Insert USB drive containing the Debian-8 iso. Reboot while pressing F12 to select boot device.
Boot Option Menu
1. USB HDD: [ENTER]
2. Windows boot manager
Install in the usual way. This does not go well. About half way through the installation process, it freezes 12% of the way through configuring dpkg and before selecting software. I tried this a few times and it did the same thing each time.
Back to the drawing board. What could be wrong? What could I alter?
Boot while pressing F2 to enter Setup. Decided to try this, simply because 'Jessie' understands UEFI:
-> Boot
----> Boot Mode [UEFI]
Re-install. And lo! This sure altered something: the install font became really small compared to before. For the first time I had some hope. Well, it installed OK this time! Run grub-install. Reboot while pressing F12 for boot device:
NO BOOT DEVICE
Ha ha ha. That would be funny if it wasn't so amusing.
Brainwave: back into setup (grasping at straws) and enter administration password:
-> Boot
----> Secure Boot [Enabled]
Now a previously unavailable menu beneath this item appears available for modification. Play with it:
Secure Boot Mode --> Custom
-> Select an (sic) UEFI file as trusted for executing: [ENTER]
HDD0 (appears at top) [ENTER]
< EFI > (appears at top) [ENTER]
<.>
<..>
< debian > (appears at top, could be on the right track!) [ENTER]
<.>
<..>
grubx64.efi (appears at top, this is promising indeed!) [ENTER]
-> add a new file
do you wish to add this file to the allowable database?
boot description [jessie boot] [ENTER]
save and exit
Reboot.
boot
error - secure boot forbids loading module from (hd0,gpt2)/boot/grub/x86_64-efi/normal.mod
entering rescue mode
grub>
OK, go back and disable secure boot - can't make the situation any worse.
Reboot. Jessie splash screen! Xfce4 login! And it all works! Can even spoof the wireless MAC (it's an Atheros chipset)!
Just loving it!
So here I was, shooting the breeze with my African acquaintance, when he showed me a copy of a report into the state of play in his country. This paragraph resonated with me:
"During interrogations, police show suspects lists of phone calls and are questioned about the identity of callers .... They play recorded phone conversations with friends and family members. The information is routinely obtained without judicial warrants."
"...without judicial warrants..." As an Australian, I felt completely familiar with this particular illegality and realised that we actually had more in common than just Linux, so we started discussing surveillance. What follows is what he told me about journalists (and savvy ordinary citizens) and what they do in his country to avoid being identified and subsequently arrested and interrogated in secret just for exercising their unremarkable right to blog or browse the web in private.
Let me fill in a little necessary background to what we discussed that day.
When you connect to a wireless access point (WAP), a lot of negotiation takes place between your computer and the WAP, the net result of which is that to continue to deal with you, the WAP gets and stores your hostname, MAC and IP address. But what are these?
The hostname is the name by which your computer is known on the network: e.g. 'mycomputer'. The MAC is the media access control address that is unique for every single NIC (network interface card) in the whole world (00:0c:fe:56:69:ab is a sample MAC attached to a wireless interface). And your IP address has just been handed out to you by the WAP for this session only (and might look like 192.168.6.221).
Which of these items can be used to identify you next time you connect to any WAP? The IP address is not important. The hostname is not so common and might be a confirming item. But it is the MAC that is practically unique, and is in your computer burned into the NIC. Not ideal, eh?
Obviously you can change your hostname for the duration of any internet session. But today you are feeling lucky. For a number of reasons, including efficiency in running a WAP (indeed, any AP), it has long been possible and routine to 'clone' your MAC. To 'spoof' it, in fact. Just such an ability suits my acquaintance down to the ground. He talked about this method when applied to wireless cards rather than ethernet cards. He noted that this is possible but a bit more long-winded with a Windows computer, and is quite difficult with an Apple computer: either the wireless chip in the computer can't be changed, or it involves recompiling the kernel. Not one of these people wants to do that, being so far from their large capital city and all the technical help you can get there just for the asking ... So they all install Linux on their laptops instead (which is how we got to talking in the first place).
Now, I asked him if I could take notes on this so I could get it right. Every time, before they go out, they chose a unique, random and typically bland Windows computer name, like 'Computer-AA4566C', and establish it in their laptop:
# echo "Computer-AA4566C" > /etc/hostname
# cat /etc/hosts | sed '/oldhostname/s/oldhostname/Computer-AA4566C/g'" > tmp; mv tmp /etc/hosts
Then they configure network-manager to 'not connect automatically' (simple enough) so they have time to do some other stuff.
When they get to their favourite cafe, order something nice, and sit down within wireless range, they boot up, open a terminal emulator, and assume administrative powers. Now to work!
They take the wireless NIC out of play before they can do anything serious with it:
# /sbin/ifconfig wlan0 down
In the past, they used to assign an arbitrary MAC to the interface in the standard way:
# /sbin/ifconfig wlan0 hw ether 3e:22:eb:9a:f0:01
but he warned me that a fabricated MAC can show up on the WAP as being from an 'unknown' vendor. To avoid suspicion they use the program 'macchanger' from the Debian archives because it assigns a random MAC that appears to have come from a genuine vendor:
# /usr/bin/macchanger -A wlan0
Current MAC: 00:0c:fe:56:69:ab (Grand Electronic Co., Ltd)
Permanent MAC: 00:0c:fe:56:69:ab (Grand Electronic Co., Ltd)
New MAC: 00:18:e5:8b:73:dc (Adhoco AG)
They make the wireless NIC available once again:
# /sbin/ifconfig wlan0 up
A bit more housekeeping needs doing. They consult 'network-manager' and make sure that the desired WAP is showing. Then they edit the connection data for the WAP: clear the 'device mac address' field; paste the new random MAC into the 'cloned mac address' field; and save these changes and quit before connecting to the WAP in the usual way. (I tried this out and it is slightly less complicated using 'wicd'.)
Then they check their connection:
$ ping -c 1 google.com
and they are good to browse!
The usual way of getting the external IP address of your ADSL modem (the address facing the internet) is to execute something like
$ curl ifconfig.me
However I find that this sometimes hangs or takes a long time to return.
You can obtain the IP address in a fast and reliable way by interrogating the ADSL modem itself. The normal method is to 'telnet' into the modem directly from your home computer. This is interactive. To make it non-interactive, so it can be run unattended, requires some blog-scouring and a bit of experimentation. Herewith (because very interesting) the results of that scouring and experimentation.
First, make sure you have installed 'telnet' and 'expect'.
My modem does this when I interrogate it:
$ telnet 192.168.1.1
Trying 192.168.1.1...
Connected to 192.168.1.1.
Escape character is '^]'.
NetComm ADSL2+ Wireless Router
Login: admin
Password:
> ifconfig ppp0
ppp0 Link encap:Point-Point Protocol
inet addr:228.106.2.129 P-t-P:xx.xx.xx.xx Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP ALLMULTI MULTICAST MTU:1492 Metric:1
RX packets:111 errors:0 dropped:0 overruns:0 frame:0
TX packets:62 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:9273 (9.0 KiB) TX bytes:3746 (3.6 KiB)
> quit
Bye bye. Have a nice day!!!
$
The 'ifconfig ppp0' command displays the external IP address 228.106.2.129 [just an example]. Thus we can construct a 'send/expect' script, named 'execute-modem-command', which looks like this:
#!/usr/bin/expect
# execute-modem-command
spawn telnet 192.168.1.1
set env(TERM) vt100
set timeout 4
expect "Login:"
send "admin\r"
expect "Password:"
send "xxxwhateverxxx\r"
expect "*>*"
send "ifconfig ppp0\r"
expect "*>*"
send "quit\r"
exit 0
We want to capture the output of this and parse it to extract the IP address. This can be done by piping it through 'grep', 'tr' and 'awk' as below.
$ execute-modem-command | grep 'inet addr' | tr ':' ' ' | awk '{print $3}'
228.106.2.129
$
(all in less than 300mS, on my RPi system.)
Of course, ADSL modems differ in their internals, and a bit of time spent exploring them via 'telnet' is needed - and is good fun - for discovering suitable 'send' commands.
Do not confuse the bashbug with the bashbug program also supplied with bash ...
There is a lot of stuff on the usual developer mailing lists describing the massive amount of work involved in handling this 'feature' [Bash-4.3 Official Patch 25].
The bug can be removed by upgrading your bash package, but if you use Debian 'jessie', as I do, then security patches are not routinely available just yet, since 'jessie' is in testing.
I consider that compiling from source is the least objectionable method under these circumstances. A downloadable tar file of the current version of GNU/bash with all official patches applied is available from savannah (see below).
First we test for the presence of the bug.
$ x='() { :;}; echo vulnerable' bash
vulnerable
$ exit 1
The printed text 'vulnerable' shows the bug's presence, i.e., an executable function (echo) has been passed as an environmental variable. The 'exit' is needed because running 'bash' invokes a new shell, even though you don't see it.
Then we fetch the source and compile it.
$ mkdir -p bash-src; cd bash-src
$ wget http://git.savannah.gnu.org/cgit/bash.git/snapshot/bash-master.tar.gz
$ tar zxvf bash-master.tar.gz
$ cd bash-master
$ ./configure && make && su -c "make install"
Fine, now test again for the bug.
$ x='() { :;}; echo vulnerable' bash
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
Squashed! -- just remember to quit the new shell.
$ exit 0
Of course, the Windows Powershell command-line is somewhat similar to Bash, so I got curious about any similar bugs in that. Here is a bug in PowerShell v3 where "an attacker can strategically place a program in the path and his program will be executed instead of the intended program.". Here is a much older one, where "quotation marks around the path lead to execution of all possible programs in the path." All interesting reading. Why not poke around for yourself, starting with the the search term 'powershell $env:path += vulnerability'?
Makes sense?
Well, that is my concise representation of a very useful tip I needed recently, and just must pass on to you! It is a recipe for forwarding an email with all of its attachments using mutt. And it's less cryptic than it appears at first.
Let's go through the recipe.
$ is the command-line prompt.
mutt starts the mail program.
[up/down] selects the message to forward.
ENTER opens that message for reading.
v displays a list of all its attachments.
tt...t marks each attachment as 'tagged' (just keep pressing 't').
;f prepares mutt to forward all these tagged attachments.
To: and you just type in the forwarding address.
ENTER ENTER copies the mail subject.
ESC leaves mutt's vi 'edit' mode.
ZZ exits vi and saves the message.
Y sends the email.
I found this at "http://shallowsky.com/blog/linux/mutt-fwd-attachments.html".
Ha! Got you in: you think I am talking about Microsoft/Windows or Apple/OSX. No such luck; this time its about Canonical/Ubuntu.
Here I am, idly researching the nature of server software for an LSGA talk. A member of our group lends me a DVD containing Ubuntu Server 13.10 to play with.
Normally you would seek an old, retired computer that can be turned into a very respectable server without doing too much damage to anyone. I have such a computer: an old laptop with an Intel Celeron M CPU, half a Gig. of memory and a hard disk with about 20GB free. Perfect.
So I play with it. First, boot Ubuntu Server.
It fails to boot; something about needing 'pae' in the kernel. This is odd. You only need the pae feature [physical address extension] in the CPU if you address more than 4GB of RAM, which my old laptop is never going to do.
So I go back to Ubuntu Server 12.10, which the download website assures me will "work on almost all PCs with Intel/AMD/etc type processors ... Choose this if you are at all unsure".
It also fails to boot; once again needing pae in the kernel.
Well, this is getting tedious. This bug has been around from 12.10 up to 14.04, which is a very long time. To have pae in the CPU requires a more modern motherboard, for sure. It is a bit like certain other systems, where you often need to upgrade to a newer machine to run a newer OS version. Only here there is no newer OS version -- after all, just about any other GNU/Linux distro will boot on this laptop! -- so what is going on?
This.
Earth to Canonical: "Please fix; my server's an old machine."
Canonical to Earth: "Too f***g bad, mate!"
Ah! Canonical/Ubuntu ... still that magnificent granfalloon that we remember from so long ago!
I came across something which might be useful if done in advance of a small but significant disaster.
I flagged an email message for deletion recently, quit mutt, and ... the message had gone! Well, so what? you might say --- that is precisely what 'delete' is meant to do. But next day I found that I needed to refer to it again -- urgently! It was pure luck that I had earlier forwarded it to a friend, and so it was recoverable.
Now I think twice before quitting mutt. However, for those who don't wish to think twice, I found this really good tip on the 'net, at "https://groups.google.com/forum/#!topic/comp.mail.mutt/cmf4JdihASo".
This exchange effectively took place there.
> In mutt when messages are deleted, where do the deleted messages go exactly?
/dev/null
> How might a deleted message be recovered urgently?...
Not possible.
...
You can avoid this by adding these macros to your ~/.muttrc :
macro index d "s=trash\n" "move message to trash"
macro pager d "s=trash\n" "move message to trash"
which fills up a directory ~/Mail/trash/ with messages 1,2 ... etc.
Nice.
My friend has a MacBook, so I try it out.
Well, here is one example at random:
[using a terminal emulator, running bash]
$ du -ab . [this is standard GNU, used every day without thinking]
du: illegal option -- b
usage: du [-H | -L | -P] [-a | -s | -d depth] [-c] [-h | -k | -m | -g] [-x] [-I mask] [file ...]
So: an error ... on my part ?
You might wonder: what part of "GNU'S NOT UNIX" had I not yet appreciated?
It's bad enough that MacOSX is based on a system (Unix) from last century, which appears to have been stuck in a time-warp for 30 years.
But what is really strange -- in fact, disturbing -- for a newcomer is the behaviour of the native browser, Safari.
First, Preferences -> Privacy tab. Block Cookies: Always.
Then go out to the 'net. And come back.
Open Preferences -> Privacy tab: there are 9 cookies there!
Clear them all, insist again on 'no cookies' [could not be plainer]
Out to 'net, back ... same result [actually, there are even more cookies].
WTF?
Known problem -> https://discussions.apple.com/message/18663883#18663883 .
Excuse me: did I say 'problem'? Not for Apple ... that's just how it's gotta be.
Firefox, anyone?
You would have trouble improving on this incisive and encouraging observation from Larry Ellison, CEO of Oracle, who is now an expert on web privacy.
Larry says "This whole issue of privacy is fascinating to me. Who’s ever heard of this information being misused by the government? In what way?"
We are so lucky to live in Australia! Our privacy is a core priority for our government! Here are the protections recommended by the Australian Government Office of the Information Commissioner. They urge [inter alia]
- Don't collect personal information about an individual just because you think that information may come in handy later.
- Tell people how you are going to handle the personal information you collect about them.
- If people ask, give them access to the personal information you hold about them.
Don't leave privacy to chance.
if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
This C language code is an attempt to backdoor the Linux kernel. It was discovered on the 5th of November 2003. I've been using Linux for some 15 years, and it has only just come to my attention through the recent NSA revelations.
It seems that the attacker was seeking to gain root access. Articles that discuss and explain it are in the Linux Weekly News and there is a sequence of emails exchanged in Linux kernel developers emails archive, and especially when the above equation was finally exposed.
Not altogether useless to have a squiz at this.
Suppose you edit a file, and after typing quite a lot of important stuff, you realise that the last line you entered is an error. You 'undo' the 'last' line, only to find that pretty well all the text in the whole document disappears! This is because you have been typing continuously, without ever leaving 'input' mode. Therefore the 'last' line was not the last line at all, but actually all the text that you typed since entering 'input' mode. And you cannot 'undo' this 'undo' by typing 'u' again; that produces no effect.
I found that the usual recipe, using :recover, fails like this:
:pre
:recover
E305: No swap file found for file
despite the fact that such a file is actually present.
So this is the usual sequence of events: open a terminal emulator [eg gnome-terminal, xterm] using 'vi' derivatives such as vi, vim, vim-tiny, etc.
$ vi file
Type a few lines without ever leaving 'input' mode [no 'ESC' press] e.g.:
line 1
line 2
line 3
line 4 in error
Now press 'ESC' to get into 'command' mode. Type 'u' to undo what you believe is the last line, thus inadvertantly deleting most of the text. Some degree of panic, of course, is in order at this stage; then sit still for a bit. Do not exit the file, because this destroys the item we need for recovery. Instead, press CTRL+z to stop the vi process in it's tracks. Now find the number of characters saved in the temporary file '.file.swp' that is maintained by the editor, like this:
$ wc -c .file.swp
12288 .file.swp
This looks quite promising ... there are lots of them; some of them might belong to us. Try to look at the .swp file contents, like this:
$ vi .file.swp
b0VIM 7.2^@^@^@^@^P^@^@^@^@^@^@:^R^@^@user^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@host^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@~user/file^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
Well, unfortunately, this contains mostly gibberish, because it is in a binary format, not text. However, we can scour the .swp file for any text strings, like this:
$ strings .file.swp
b0VIM 7.2
user
host
~user/file
3210#"!
line 4 in error
line 3
line 2
line 1
Ha! This contains all your lost text! (in reverse order, however.) No problem -- just reverse the order of the lines and restore the contents of the file, like this:
$ strings .file.swp | tac | tee file
line 1
line 2
line 3
line 4 in error
3210#"!
~user/file
host
user
b0VIM 7.2
Then edit the file and remove the unwanted lines near the bottom. And all is done -- fantastic! Note, however, that this does not always work. If there has only been a short time between slip, cup and lip, then some buffers might not have had time to be saved. Best of luck !
Reference PC benchmarks the normal situation.
CPU=Intel Core2 Duo E8500; speed=2000MHz; memory=2000MB.
Raspberry Pi is a favourite, spawning myriad projects with its array of I/O pins.
CPU=ARM1176JZ-F; speed=700MHz; memory=512MB.
CuBox is a relative newcomer; faster processor but no real I/O capability.
CPU=ARM PJ4 v7; speed=800MHz; memory=1024MB.
Three movies of these types are played on each device.
AVI (50Mb) - RIFF data, 640 x 480, 30.00 fps, Motion JPEG, uncompressed PCM.
WMV (6Mb) - Microsoft ASF.
MP4 (64Mb) - ISO Media, MPEG v4 system, version 2.
This is how long these movies take on each device.
AVI --- 27s on PC --- 70s on RasPi --- 79s on CuBox.
WMV --- 82s on PC --- 182s on RasPi --- 91s on CuBox.
MP4 --- 79s on PC --- 1659s on RasPi --- 139s on CuBox.
If you prefer not to use gnome3, like to boot to a console instead of a GUI, and are irritated by long-standing bugs, then read on. What follows has been harvested from the 'web and thoroughly tested.
Fix the ‘/bin/df’ bug which is still producing unsatisfactory output.
# edit /etc/default/grub
(and delete the '#' character in the line ‘#GRUB_DISABLE_LINUX_UUID=true’)
# update-grub
Grab a decent desktop environment.
# apt-get install xfce4
Boot to a console instead of a GUI.
# mv /etc/rc2.d/S19gdm3 /etc/rc2.d/xS19gdm3
Make the X-server 'zappable' in case of problems.
# edit /etc/rc.local
and add the line
setxkbmap -option terminate:ctrl_alt_bksp
And finally, try again.
# /sbin/reboot
The system now boots to a console (e.g., for running # apt-get dist-upgrade), and the command
# /etc/rc2.d/xS19gdm3 start
allows you to login in the normal way and to specify Xfce as the default.
If you are feeling adventurous, try installing MATE instead of Xfce4 [and best of luck!]
Suppose you want to list all the photos in the current directory with a size greater than 150000 bytes, using a bash script. You could do worse than something like this:
du -ab . | awk '$1>150000 {print $0}'
160000 photo1
170000 photo2
200000 photo3
However, if that minimum size was not a fixed number like 150000 but was typed in from the terminal whenever the script was run, you could instead do something like:
read -p "enter minimum size < " min
du -ab . | awk '$1>$min {print $0}'
which, to your amazement, consternation and finally disbelief --- produces absolutely nothing !
What you rather need to do to transfer the value of the variable 'min' into the 'awk' statement is something like this:
read -p "enter minimum size < " min
du -ab . | awk -v size="$min" '$1>size {print $0}'
! ... delightful ... !
The subtle (and hard to diagnose) problem arises when you want to try something like this:
option=no
cat file | while read line
do
...
option=yes
...
done
echo $option
no
Because of the separate process created by the pipe, the internal variable (here set to 'yes') is not visible to the rest of the script (outside the 'while...done' loop). The correct way, I found out (yes, after much 'web-crawl!) is to create no pipe, but redirect the file as input to the 'while...done' loop. I know this looks a little weird, but it works fine because no subprocess is created. Thus:
option=no
while read line
do
...
option=yes
...
done < file
echo $option
yes
Unlike ping, fping is meant to be used in scripts, so its output is designed to be easy to parse.
For example, sometimes it will be more convenient to use
$ fping 192.168.1.250
192.168.1.250 is alive
rather than using the more verbose
$ ping -c 1 192.168.1.250
PING 192.168.1.250 (192.168.1.250) 56(84) bytes of data.
64 bytes from 192.168.1.250: icmp_seq=1 ttl=64 time=1.22 ms
--- 192.168.1.250 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.222/1.222/1.222/0.000 ms
Another example: if you want to check the interfaces on your home LAN, try
$ fping -c 1 -g 192.168.1.0 192.168.1.255 2>/dev/null|awk '{print $1}'
192.168.1.16
192.168.1.240
192.168.1.250
$
which lists three interfaces that are up and configured.
Admittedly, everything fping can do can be done using a bash script and ping, but for those without the skill or patience, fping might be a godsend.
The URL "ifconfig.me" is that of a website at http://ifconfig.me, which will parse your request and return the address to which it sends the result -- which is just your public IP address (on the other side of your modem).
For example, if you have an ADSL modem with LAN address 192.168.1.250 on the PC side, and you try the command, you might get something like
$ curl ifconfig.me
212.45.199.7
Some blogs claim that you can get the same result with wget (if curl is not installed).
However, there is a bug in older versions of wget (e.g., GNU Wget 1.11.4) that causes this to happen:
$ wget -q -O - ifconfig.me/ip
wget: missing URL
Usage: wget [OPTION]... [URL]...
Try `wget --help' for more options.
... And a coupla bonzer jokes ...
WARNING: this one might be critical of Windows
And this one is just for you Command-Line junkies
| So what's the best distro. around? Well, there are so many of them that it is hard to know. | But before you make up your mind, check out this great summary about why Linux is better. |
| Love this ! from The Bizarre Cathedral at freesoftwaremagazine.com! | See it at the original site and size. |
| When security is important, you really need software that has been thoroughly checked-out for holes. | This is not a Linux distro., but OpenBSD might be a better bet to have between your distro. and the Web. Check it out sometime soon. |
| GNU/Linux is great, no doubt about it; that's why this site exists. But that does not mean you should force your mother to use it! | Have a look here to learn why Linux is not Windows and adjust your advocacy to suit. And did I forget to mention that I love this guy's attitude! |
| Tux is somewhat lovable, of course, but ... Linux developed from Unix, which, not so long ago, was viewed by many as being quite unlovable indeed! | Have a look here to discover if you are already a Unix-Hater or to see how you could become one without too much effort. |
| This is what the command line feels like when you first try it out (and for some time after that, too!). | Peek at this if you still want to try the command line using bash, the Bourne-Again Shell. And here is an excellent command-line tutorial. |
| There are so many Linux shells, and yet so little time to gather them all, let alone try them out. | So here is a quick comparison of various Linux shells and even more Linux shells just so that you know what is around. |
| There are some really good courses on Linux on the web, and here are some links to them. | For an easy-reading and very comprehensive overview, try this as an introduction to begin with. |