lesson ten: slackbuilds and baking

see.. i getz slackbuilds now.

source code = ingredients.

slackbuild = recipe.

building the file = making the cake.

installing the file = baking it in the oven.

oh and i lovezzzzzzzzzzzz the new sbopkg.. lovelovelove!!! Thanks and lots of kudos to chess, the developer…

lesson nine: turning Pat into a chav with the inits

If you’re signed up to the Slackware Security Mailing list (and if you’re running Slackware, you really should be, like a good little Slack Bunny) then you’ll notice that rather a lot of security updates dropped into your mail box this morning. Ten of them, in fact. I waited for Michiel to sync the mirrors, then i updated (see lesson eight). At this point Michiel decided to totally distract me from the mound of sewing repairs i was supposed to be doing.. and give me lesson nine instead… on daemons, inits (no, not innits – despite the title, we’re not a bunch of Chavs), and pretty colours in Konsole.

Occasionally Pat will change the config files – the files that are involved somehow when Slackware starts up. these are kept in the /etc/rc.d/ directory, they’re called init files (from Initialisation, not the chav thing) and you can tell they’re init files cos they all start with rc. Its important as a good Slackadmin to keep track of these changes – when they’re made, the extension is always .new so that they don’t automagically install, and gives the admin the chance to check the changes and see if they’re changes they’re happy with (for all that Pat is called The Benelovent Dictator for life, he doesn’t do a whole lot of Dictatorship stuff. I guess that’s the benelovent part. ). If the Slackadmin is happy, then the changes can be made, but with backups of the old config files kept so that if there are any problems, the changes can be undone without too much of a problem.

You can tell that there are changes to the configuration files because when slackpkg is run (see lesson eight) it asks the slackadmin if they want to keep, overwrite, remove, or prompt. In my case Michiel’s already had a good look at the changes way before i get to updating, so this isn’t something i have to worry about just yet (thankfully).

One of the changes that was made this time around was to the ssh daemon. ssh is short for secure shell – its basically a secure, encrypted connection between one computer and another. the daemon is the process that controls this – you can think of it as being like a little red demon, pitchfork n all, that holds the door open, but only allows approved traffic through. Kind of like a bouncer, if you like. if you stop the daemon, by going to the /etc/rc.d/ directory and typing ./rc.sshd stop then it kind of freezes the demon, and he can’t hold the door open any more, and all traffic controled by that process stops. to “open the door” again, you go to the same directory (if you’re not already there) and type ./rc.sshd start – However, if you are working remotely on a box, and you stop the daemon, then you effectively lose your connection, so its not a good idea to do this unless you have someone physically on the other end to type the start command.

Something i noticed while in konsole, looking at all the init files, was the different colours, and at this point i asked Michiel about them. Seems they’re standard colours, they act as a visual representation of the different file types. dark blue is directories. green have the executable bits set (in other words, they do stuff). cyan ones are symbolic links to other files. Grey files are normal colours. Purple files (someone call for Londo! [sorry. bad Babylon 5 joke]) are images, and red files are compressed archives. Yellow ones are device files. The different colours can be checked in Konsole by typing view /etc/DIR_COLORS.

and there endeth lesson nine!

lesson eight: security upgrades

photo courtesy of that cheeseburger site..

Slackware occasionally has security upgrades, and the smart geek will have signed up to an email service that tells you when there’s a security upgrade available (and you can do this here, if you haven’t already). Today was the turn of something called Ruby, and although i’ve done these upgrades before, i haven’t written notes on it. so. notes:

[normally you need to grab a copy of the security update before you can install it. in my case, Michiel has already downloaded it, and my machine is set to look to his for a mirror, so this is not something i have to worry about.]

open a terminal.

switch to root with sudo -i, and type in your password (note to self: user password!)

type slackpkg update and let it run.

type slackpkg upgrade-all and let that run.

Wait for the blue screen with the list of files that need upgrading to pop up. make sure they’re selected and press “OK”. then let the upgrade run.

Et Voila! upgrades are done.

now type exit twice, once to log out of root, once to close the Terminal.

lesson seven: slackbuilds

i made a fatal mistake last night. I was bored with the games that exist on KDE, so instead of asking Michiel for some more i went looking to see if i could find some. I found this article, which recommends the top 10 free linux games, and not being interested in FPS, and having all the rest, the only one remaining was “Pingus“. That was the really really bad mistake: idly commenting “mmm, wouldn’t mind playing that”.

two minutes later i found myself working with slackbuilds!!! whaaa? where did slackbuilds come into it?! i only fancied playing a little game, not downloading/extracting/installing stuff, and WAHHHH working with root!!! (DO NOT WANNNNNT!) However, it turns out, to my total and utter surprise ($clue: sarcasm) that the Slackbuild team (specifically ppr:kut thanks ppr:kut!) maintains a Slackbuild of Pingus and that that’s the best place to download it from (well Michiel *would* say that wouldn’t he?). so i do. rather nervously. I find the relevant page for Pingus, then ask “now what?”. he points me to the HowTo page, and i nervously download the slackbuild (the .tgz file, in case anyone was wondering). Michiel directs it to the right directory (and i’m still very confused about this process but maybe writing it all out will help), then extract it, using the tar command (tar xvzy filename. i think. something like that anyway. Hey, i’m going off memory and it was 2am at the time…) and then i download the source. The first time i do this from the webpage, later we do it another way which confoozes me still further (and i’ll say this before Michiel does: it doesn’t take much.. to confooze me that is).

once all that’s done we execute the script by using the chmod command (as described on the HowTo page), and then, of course, we run into a problem. Turns out pingus has 3 dependencies (someone didn’t read the top of the pingus page properly.. both of us) – boost, scons and physfs. apparently i already have boost on my system (as Straterra said: thank god, compiling boost on a little PIII would be a nightmare, apparently) so i had to download the source file & slackbuild instructions, and extract, execute and install both of these before we could execute (compile) the pingus slackbuild properly.

And this was the part that *really* confused me for a while as Michiel was telling me to download the source file using wget, which i hadn’t done before, and telling me to move the package after it had been compiled from /tmp/ to packages (I think i got that right) and Michiel was patiently sitting there saying to me “where’s the package” and i honestly felt like screaming back at him “WHAT EFFIN PACKAGE?!!!!”. *ahem*. I’m not the most patient and calm of learners at the best of times (yes, i know, Michiel.. thats the understatement of the century but i’m trying to be nice to myself, ya hear?). another time i’d just hit return on an installpkg command and he gasped like he’d just seen me make some terrible horrible computer killing mistake and … then said “nothing”. he got called a choice collection of names at that point i can tell you.

All joking aside.. we were finally compiling pingus, side by side, him compiling it for 12.1, me for 12.0, and of course, his being a rather better model of computer (dual core, just for starters) than mine (a slow, but patient little PIII) he finished first. And then he started to explain to me – within hearing of my PIII – just why my PIII is so slow!!! Poor thing. I had to cover its ears and whisper reassurances to it. Speaking disparagingly of my baby. how dare he.

and for all that.. I’m actually quite proud. I installed something off Slackbuilds. okay, i did it with a lot of handholding and i’d have to do it with handholding next time but.. i did it. without flaking out too much (I don’t think i will *ever* like working in root).

so.. go me!!!

lesson six: irssi

it won’t have escaped anyone’s notice that this blog went a bit quiet for a while. I’ve not been well, partly (teeth troubles), but also because i’ve been doing some of my other love: the garden.

An incident today (which i won’t go into here) led Michiel to set up irssi as a chat client for me. I said i would give it a go, rather than using Konversation. I’ve been feeling more confident about using irssi, since i started hanging out in ‘chucks and other geek chatrooms because i’ve been able to look over at his computer, see what he’s doing with his screen and observe that its not such a mysterious thing after all.

(if i have one criticism of Michiel as a teacher, its that he’s so good, its almost daunting to try to learn from him… kinda like.. “OMG i’m NEVER gonna be able to do that!!”. he’s fast on the keyboard which makes it hard to follow, but at the same time good in a way that makes it look very easy, while looking hard. if that makes any sense.)

However, he sent me off to choose a theme for irssi and it was in chatting to my best friend, sez, who isn’t a geek (although she has used linux, to her credit) about what was happening that i realised she’d never seen irssi as a chat client, so i promised to take a screenshot of it for her. Then i remembered this blog and.. well. an entry is well overdue (plus something else… more on that later).

So without any further ado.. i’d like to present.. my irssi:

Do i like it? so far. I’ve only got one complaint. Konversation, when your name is said in a channel, or someone pm’s you, briefly flashes the content of the message on the screen over whatever you’re looking at (i.e. firefox), and then flashes the lil konversation icon between blue and red in the bottom right hand corner. Irssi doesn’t do that. (Michiel would say that’s because Irssi is meant as a proper chat client, because its IRC and not meant to be insta-response… i’m sure he can tell you better than i can but.. you know.. i like to know when people are talking about me!!!) I don’t like using it on Michiel’s keyboard. With Irssi you move between the various channels by holding down the ALT key and each channel has a number. That’s great, when you know where the number keys are.. although i’m a speed typist i don’t know where the number keys are, necessarily, and moving around Irssi on Das Keyboard is .. a pain in the backside.

Apart from that, i like it. it feels like a proper geek’s IRC. i feel like a proper grown up geek using it. I could get used to it, i guess.. if i do i guess part of my transition has begun. I remember when Michiel first yanked us away from Windozs to Linux, bewailing the loss of my beloved mIRC… i tried out a few chat clients. Michiel suggested irssi. Wasn’t about to have that, i wanted Point n Click!. i wanted ease and simplicity! ahem. yes, i know better now.. i finally settled on konversation and now.. 3-4 years later.. i’m using the irssi i was so afraid of.

better late than never, i guess..

lesson five

hanging out in ##woodchucks, rob0 makes a comment that he’s: “editing apcupsd stuff. I cannot let it power off the machine in a shutdown. I made a special runlevel 2 which is like 1, but has network and sshd and syslogd”. this is a classic example of something that makes me go.. “huhhhh?” so i go looking things up to try to understand.

[And usually, i enter what i'm beginning to call "Acronym hell" (like dependency hell, but with acronyms). take the apcupsd. I put it into google, and i get the website for it straight away, which is good, but its not terribly informative to someone who is very new to stuff. "Apcupsd can be used for power mangement and controlling most of APC's UPS models on Unix and Windows machines. Apcupsd works with most of APC's Smart-UPS models as well as most simple signalling models such a Back-UPS, and BackUPS-Office." uhhhhh... huh? and no links as to what most of this means. so i go to wikipedia. which is better, in that i can follow links where i don't understand.]

Anyway. apcupsd is a program, a daemon (a background process program) that works with APC (a company) uninterruptible power supplies (which is the thing that saves your computer going up in smoke when there’s a power spike or cut).

runlevel is the thing that describes where the computer is in any stage.. so when you’ve just turned your computer on, its in one run level, when its in the XWindows its in another. Slackware has six levels. level 1 is single, level 2 is full multi-user with no display manager. (whatever that is). ahah… just spotted on the wikipedia page: “Lower run levels are useful for maintenance or emergency repairs, since they usually don’t offer any network services at all.”.. so.. maybe what rob means is he’s making a special thing that runs the computer at the minimum level possible, that keeps the stuff he needs running, running, in the event of a powercut, so that the UPS keeps the machine running for as long as possible before that runs out too.

[and yes, I'm well aware it would be far easier to actually ask rob what he meant by it all but that's missing the point: by doing this and going and looking stuff up i'm learning. and i probably will ask him at some point cos he's got no idea i'm doing this right now.]

sshd = secure shell. i guess so he can run some command stuff. that would be pretty necessary i guess. syslog.. hm. ahhh ok i think i see why this is necessary, so it can record what was going on with the computer so if there’s a problem, rob can see what it is. that makes sense too.

so i get it. i think. i’ll ask him later if i was right.. i think he’s a bit busy atm.. !!

lesson four

One of the tools Michiel has given me to help me learn is a book; “Linux Start Up Guide” by Fred Hantlemann. I’ve been reading some of it before i went to bed the last few nights (to be truthfully honest, mostly because reading just a couple of pages has me snoring before i know it. Its not boring or anything, more that.. well, mention words like “variables” and my eyes start closing of their own accord. annoying, really), and finally got to the point where, really, i had to start trying some of what i was reading if i was to make any sense of it (you know, the old “Tell Me I will forget, Show Me I will remember, Involve Me I will understand!”).

So Chapter 3 (“Operating Linux”) so far has had me using the whoami, the who am i, the id and the set commands, the ps -al command, the ls one (which i knew already) and ls /usr/bin | more, and more /var/log/debug which gave me a rude reply about not having access. well to you too matey.

It then went into detail about how to move and copy files, using the cp and mv commands, and how to make a directory (mkdir).

Then it started in on Vi. Now, this i’d heard of: Michiel had gone to some effort to explain to me why emacs = bad and Vim (the uptodatebigbrother verson of Vi) is good. not that i was any the wiser, then, as i didn’t really understand what an editor was. to me, an editor is the person in charge of a magazine. So i went looking on the intertubewebthingie to see if i could understand it a bit better. Wikipedia was a start: it led me to a page on why Vi (pronounced Vee-eye, not Vie) was the greatest gift to man, and why some nutheads use Vi/Vim. (at which point i turned to Michiel and asked him, is Vi/Vim good? he said yes. so emacs is bad. at least, from his perspective. Do i agree? no idea. yet. ) so i think i understand now, what an editor is. its a program that lets you write. you can write normal text (although you’d be better off using a word processor or something if that was all you wanted to do) but you can also write programs. However, there’s a catch. in order to execute (i.e. run) your new program you either have to use the command interpreter to execute the contents of it, or you can mark the file as an executable.

huh? okay.. whats the Command Interpreter? (reading these things is frustrating: you understand one thing and get 20 more questions). Well, that was the next bit of the book, funnily enough, and the bit that sent me back to the intertubesfount-of-all-info. According to the book, the job of a Command Interpreter is “to analyse, or interpret command lines entered by the user and start any programs cited”. well, hey, that sounds like konsole, which is what Michiel tells me to use when he wants me to do something (and i’m slowly getting less scared of). and this goes back to another conversation we had, where he tried (and failed, although not his fault) to explain the difference between konsole and Bash (as an example of a Command Interpreter). Wikipedia was my starting point (Its not for nothing i’m known as wikislut), although not terribly illuminating, it was thinking about what i’d read in the book and everything else i’d learned that finally clued me in: Bash will do a lot of the things Konsole does, but Bash does more than Konsole does too. Konsole will only run or execute files, Bash will do the analyzing part as well.

So.. to make a program you have to write it first in an editor like Vim (or the much hated emacs), then use a command interpreter to analyse it and get it to run. analyse.. meaning check it works? Maybe i’ve got my understanding totally wrong, but it seems like a terribly long winded way to go about it. why not one program that will do everything: write the code, check it for bugs, then execute it?

hmmmm. see what i mean? … understand something.. get more questions.. argh!!!

I’m going to go have a bath and think this through some more.

lesson three

thanks to fred (he of the “do-not-click-that-link” fame) i now know what had, in my head, been called the thingiemahjig before now, is really called. its a backplate. (apparently he is jerryrigging one). a video on how to install one can be found here. Duct tape is a wonderful thing, by the way. no, not for gagging me, for sticking together a blank backplate to an IDE controller. i think, anyway. (I do know it came with a PCI backplate that is ATX incompatible, and no, i don’t know what any of that means either).

lesson two notes

how to deal with a headache induced by Michiel attempting to explain how bash is both a language and a program (shell) and konsole uses bash but isn’t a shell: crack open a cadbury’s creme egg and dunk 48% cocoa solid chocolate squares into the fondant egg. then sit back and enjoy the sugarrushrrrrrrrrrrrrrideee… *twitch*

moving around within the command line:

rm = remove
cd = change directory
ls = listing
Q = quit
less = view the contents of a file one page at a time.
man man = manual pages.
man = manual pages so man XXX would be manual page for XXX (fill in the gaps with a program name)
mc = midnight commander, a sort of command line version of file manager

man 1 XXX = first page of the man page for XXX program

File structure of linux:  called the Filesystem Hierarchy Standard, maintained by the free standards group, although not all of the contributors obey it. (they’re norty). But slackware does. YAY for slackware! so most things on linux/unix computers that obey this will be found in the same place. Useful.

back to the packages thing:

files within packages aren’t all within the same place. important point, this! its not like windows where you have c:/programfiles/microsoftoffice or anything like that. the packages have index cards within the box that tells you where the file is, not that the file is necessarily within the box. also packages aren’t always the same as the program, although sometimes they are. (looks like it can never be simple. huh.) this page has useful info on this.

final note: GUI = Graphical Interface = point n click programs that you love.

lesson one notes

compile = build. configure = specifications.
all programs come in source code.
slackbuilds are just instructions for turning source code into a package suitable for slackware.
a package is a box that contains files.
to make a package run on your system you need to use a package manager – in slackware, that’s pkgtool.
there are some good and bad package managers out there. slackware’s package manager is good cos it doesn’t address dependencies for you, it assumes you have addressed those yourself so forces you to take full control of your own system.

all packages are also archives, so a tgz or tar system is also an archive and a package.

configure script = the bit of script that tells the package manager *where* to install things.

where to store things:
/bin and /sbin = program files that is the basic basic level to get box running, no mounting of other partitions
/usr/bin and /usr/sbin = other program files like KDE, kmail, kobe, etc. but are going to be common to all users on that computer.
/usr/local/bin and /usr/local/sbin = stuff that’s really only for the one usr

if you install a package without a configure script it will automatically try to put it in /usr/local but this is not right – good practice file trees say most packages should be put in /usr. only a few things get put in /usr/local, usually things that cannot be packaged because either the developer is shit or there’s no point because all the files for that program are kept in one directory anyway like SL or UT.

Linux is different to windows in that if a program uses lots of files, windows stores the files for one program in one directory, and if another program needs the same file then it puts the file on your computer twice (in a different place). Slackware doesn’t do this, so if program A and program B both need File X then file X is put in location B and program A and program B contain references to it and where it is.