OKC Steampunk Expo 2011

19 04 2011

This past weekend I was able to head up to Oklahoma City for the OKC Steampunk Expo. The event was a lot of fun for 25$ (Saturday pass). There were a good amount of vendors selling a good variety of items. I was able to obtain quite a bit of merch that I had been looking for (Ughh…spent far too much $$$…Yeeaaa got some REALLY good stuff). The hotel wasn’t the best place to host the event in my opinion as it was an odd layout and kinda cramped, but they made it work.

I got introduced to Shmoocon and am planning on attending that this year. I also got to meet several craftsmen/women, artists, and shops that are in the OKC area. I can’t wait to explore their shops.

While I did enjoy the fact that they had performers playing in the atrium all day, they didn’t have the speakers setup properly for speech. The music groups sounded great, however, the groups that just talked sounded muffled and muted if you weren’t next to them. They had three guys up there one time and they looked like they were having a great time but I couldn’t understand a word they were saying. Something about bad movies I think. They could have just been making Charlie Brown teacher noises for all I know. Wha-wa-wa-wa-waaa 🙂

I did have issues with how the event was run. Every time I asked a question to one of the staff it seemed that they had to call someone else. In fact, it seemed to be the same 2 or 3 people that questions were asked to. One guy (attendee) I talked to kept asking the staff about the event programs which didn’t show up until almost 5pm on Saturday. No one seemed to be able to give a reason for why besides issues with the printer (again, only a few people seemed to know about what was going on). The guy didn’t seem too thrilled as he claimed they had paid for an ad in the program. Not only was the program missing for the majority of the event, but he didn’t see the ad in the program. I heard them offer a refund, but still…Eek! Feel bad for the guy. He seemed to be excited about the ad too…

**Warning: over heard conversation**
It wasn’t just me who noticed the confusion. Several of the vendors were openly complaining about the vendor room to each other. One even joked about packing up half way through the day. I don’t know how much of that was HaHa joking vs joking-but-kinda-serious-too. Either way it can’t be good when the vendors joke like that in front of staff and attendees.

I understand that this was their first big event and believe me, I don’t know if I could have done as good of a job. However, having attended several big events I do kinda understand how things should work. There should be a hierarchy chain of command. There should be certain people responsible for certain actions/items/events and held responsible for those actions/items/events. The people who know every detail should NOT be running around putting out fires as that should be COMPLETELY delegated out to another responsible party. They should only be there to oversee the whole picture.

Relying on a handful of people to run the whole event HAS to be stressful on everyone. Stressful for the people doing everything, stressful for the people relying on leadership, stressful for the vendors, and aggravating for the attendees.

I can’t wait for next year. I really hope that they don’t get discouraged by the craziness and they they learn from it to put on a better show next year.

I also really hope that they get Abney Park next year. But that is probably just a fanboy fantasy on my part 😀 I was REALLY pleased to hear several people playing Abney Park on their portable music players though.

😀





Texas Linux Fest 2011

19 04 2011

I got the chance to crash the Texas Linux Fest again this year. It was a blast.

This year was so much better then last year. They really stepped up their game and put on a great weekend*. Sure there were a few hic-ups with things, but they seemed to recover pretty fast.

* Not that last year was bad, they just really improved.

The only complaint that I have is that they put on the tutorial sessions on Friday morning. I wasn’t able to convince work to let me off for the day and while talking to a few others on Saturday it seemed that they also had similar complaints about being unable to make it.

Oh well. Hopefully they can move the Friday events to the afternoon or on Sunday next year…or that I can convince work to give me the day off 😛





My thoughts on the nine traits of the veteran Unix admin

16 02 2011

I read a interesting article by Paul Venezia called “Nine traits of the veteran Unix admin.” You can find it here. Please, do take a moment to read the article. It might help to understand some of my comments, plus it is a decent read.

Having worked with Linux personally and professionally for over 11 years now along with Unix, HPUX, Irix, and Solaris on occasion, I thought I would offer my thoughts on the article. Especially since he seems to have gotten really close to describing me without ever meeting me…

“No. 1: We don’t use sudo”
The first ‘Wow, that is what I do’ moment was near immediate. The quote “the first thing we do is sudo su -” pretty much describes me to a ‘T’. That is almost always the first command I run when I boot into an Ubuntu live cd.

The only “objection” I have to this is, there are certain times when sudo is necessary. I admin a few servers that are as locked down as tight as we can get them. The root account is locked in every way. The root account and all activity are tracked and monitored. Any admin running commands as root (or su), get flagged on our monitoring system. The only way to work on that box is sudo for the sole purpose of tracking and monitoring what each admin does on that box. It works well and that is about the only time I use sudo.

“No. 2: We use vi”
Damn straight.
Thanks to the Single UNIX Specification, I KNOW that vi is going to be on every system by default. So I KNOW that I have a great editor at my fingertips no matter what system I am on.

“No. 3: We wield regular expressions like weapons”
XKCD jokes aside, if one knows how to wield and document regular expressions one can do near anything.

“No. 4: We’re inherently lazy”
Fully agree. This is why I do everything I can to master the Bash shell. I can automate so much of what needs to be done it isn’t even funny. It may take me a while, and I monitor everything closely, but it gets done and chances are good I don’t have to do it again. Which means I can devote my time to something else AND I have another solution/script in my code repository I can re-use later if need be with little effort.
Oh! Also, screw Angry Birds. Frozen Bubble is where it is at.

“No. 5: We prefer elegant solutions”
I am just going to re-quote Paul on this one because he nailed it perfectly.
“If there are several ways to fix a problem or achieve a goal, we’ll opt to spend more time developing a solution that encompasses the actual problem and preventing future issues than simply whipping out a Band-Aid. This is related to the fact that we loathe revisiting a problem we’ve already marked “solved” in our minds. We figure that if we can eliminate future problems now by thinking a few steps ahead, we’ll have less to do down the road. We’re usually right.”
Can I get an Amen? Amen!

“No. 6: We generally assume the problem is with whomever is asking the question”
I don’t like to be thought of as arrogant, so I try not to be even if others think I have earned it. I will investigate and I will honestly try to find a solution to a one-off-random-happen-chance error, but if I can’t reproduce it chances are I am going to chalk it up to user error. Why? Because it almost always is (sorry; just a bit of the arrogance slipping out). If it happens twice, I will set traps and monitor log files. If I can catch the error, chances are really good that I am going to do what I can to find a solution as long as time, effort, and $$$ permit. I also HATE the Band-Aid philosophy as an admin. I want an elegant permanent solution if I can get one.

“No. 7: We have more in common with medical examiners than doctors”
Once again he hits the nail on the head. Ties right in with the last point. I have detailed monitoring setup with Zabbix for my network and my systems and I expand its capabilities and items it monitors weekly. When something happens, I want the log files to tell me what happened, why, and what I need to do to prevent it from happening again.

“No. 8: We know more about Windows than we’ll ever let on”
Damn monkeys that call themselves Windows Admins. Don’t get me wrong, there are plenty of smart Windows Admins. However, the really bad ones that piss me off are the ones that cause all the trouble. The idiots that really drive me crazy are the ones that wave their MCSE’s around like it is proof they know something, then are completely incapable of thinking outside of the step-by-step guide given to them. These idiots often say ‘It works! Now don’t touch it!’ and won’t do even the basics such as applying security updates (MCSE = Making Computers Susceptible to Exploit). If you ask them to do basic tasks they give stupid excuses (or worse promises) to make you leave so they can hurry back to their desktop games (aka MCSE = Minesweeper Consultant / Solitaire Expert). They have no idea what they are doing. They click this button, then click that button, then click agree, next, next, finish, and then assume that everything is ok. Don’t bother wasting your time telling them they configured something wrong. They will dig up some tutorial book for Windows NT 3.5 as proof for their Windows Server 2008 configuration. These idiots are so scared that someone will force them to learn something new that they are usually the most vicious defenders of buying off the shelf software (God help you if you get caught in their fanatics if someone suggest they learn a new OS! Even another version of MS Windows will set them off!). These idiot admins CAN’T fix problems on their own so they HAVE to buy support and they absolutely depend on management buying whatever they need (MCSE = Management Conned by Something Expensive).
This means whenever something of theirs breaks and that breakage even hints at disturbing anything in the Linux realm, ___I___ have to fix it. Nothing would make me happier then to never touch another Windows box and ditch any and all ‘knowledge’ I have of it, but as long as these idiots are still around I will probably have to fix their servers for them.

PS: Why is it that for every MCSE that I meet who actually knows what he is talking about, I end up dealing with 10 who I am surprised that they managed to fill out their name on the test correctly? Also, if the test is so damn easy and cheap that these idiots can get one, why is it such a highly esteemed certification? That still baffles me to no end….

“No. 9: Rebooting is almost never an option”
I wouldn’t say ‘never an option’…but the last reboots I had were due to kernel updates, a bad nic card I needed to replace, and to run a diagnostic on the root drive that required it to be offline. I will agree with this statement “If the problem occurred once and was “fixed” by a reboot, it’ll happen again.” I have seen this with Windows, OSX, and Linux. Something goes weird and the user reboots every time. Soon they are rebooting several times a day because they never fixed the problem.

My servers have high uptime because they are stable and I know everything running on them and how to fix those programs/services when (if) they have issues. My uptimes can span years and are on legit servers. Not a box that sits in the corner of the room that no one ever logs into.

On the flip side of the coin, I know someone who was hacked pretty bad because he refused to update while he was chasing the holy 5 nines. The hole they got in through had been patched over 9 months previous to the hack. This is why I watch all the security lists for Debian and CentOS (the distros on my servers) and I am more then willing to sacrifice a silly uptime number to apply a security patch.

Lastly, I can’t think of a better way to end this then the statement he had. So I am just going to quote Paul one last time.

“If some of these traits seem antisocial or difficult to understand from a lay perspective, that’s because they are. Where others may see intractable, overly difficult methods, we see enlightenment, born of years of learning, experience, and most of all, logic.”





More Bash 4 features I need to remember

26 01 2011

Found a 4 part article on Bash 4 on LinuxCommand.org Blog Site. Read a few more things that I really need to remember.

I am totally going to swipe their code….
1) New way of reading files
# Old way
while read line
array[i]="$line"
i=$((i + 1))
done < file
#New way
mapfile array < file

2) Just visit the website and read up part 3 on the ‘read’ command
In short, you can now supply default text in the read command.
read -e -p "What is your user name? " -i $USER

Thats all for now. I am sure I will find more new tidbits soon.





Bash habits I need to break and habits I need to make.

22 01 2011

I got started with Linux back in the summer of a 1999 while a friend and I messed around with Turbo Linux, Red Hat 6.0 (5.2? maybe? Can’t remember exactly), and Mandrake 6.0. I stumbled around quite a bit on the shell and the GUI was no where near as good as it is now. One day while at the bookstore I saw that they had a great deal on computer books. A few of them caught my eye and so I bought them. One of the books was Unix Shells By Example 2nd ed authored by Ellie Quigley. It is hard to explain the history that I have with this book.

First, I can’t believe that I have owned this book for over 10 years, though it does show. Some pages are practically falling out (just barely hanging on), the spine has been broken, and when you set the spine on the table and let the pages fall open the book opens straight up on dealing with arithmatic in bash using exec (a particular task I had years ago where I had to do complex math to pass parameters to a scientific computationally hungry cluster and the book was in use all day every day and I only ever turned a few pages back and forth).

Next, it shows that I have gotten FAR more use out of this book then the $40 I spent on it all of those years ago. Probably one of the top 5 purchases of my life.

Lastly, it is a reminder that at the ripe old age of 28 I am not far from yelling at kids to get off my virtual lawn…seriously. I mean I cut my teeth on versions of bash shell around the release of bash 2.0 using Linux kernels 2.0-2.2. Over the years I can and have done some things using bash scripts that hardcore programmers wished they could do in their compiled language of choice. An example is that large cluster of computers doing very complex math and all interacting with each other over ssh (using keys). It took over three years before the C++ programmers could get the overall performance that I had using bash scripts.

Sure, I have sorta kept up with things as the years have gone on. Dave Taylor has my favorite articles every month in the Linux Journal. However, I hadn’t quite realized how far behind I had fallen. This month at my Linux Users Group, one of the guys was talking about how he was so exited that Debian (a favorite distro for both of us) was going to have bash 4.0+ in their squeeze release. So? It is a Bash shell. What can they possibly do to get excited about?

So I went and read a TON of information on Bash 4.0. Which then branched out into a ton of other stuff that they have done that I have some how missed. I guess it showed me that even on things I thought I knew inside and out, if I don’t keep up with the changes I get left behind. I have compiled a list of things that I am going to start working on to improve my shell scripting abilities even more. I think I may have to finally retire my Unix Shells book. If you have a suggestion on a newer shell scripts book that you think will last me another 10+ years, please let me know in the comments.

Thanks!

PS: Another sign of me getting close to yelling at kids to get off my virtual lawn. A guy at work was talking about a problem with his new laptop and Ubuntu. He complained “Then [the guy on the forum] told me to try out the patch. When I asked him how I was supposed to do that he told me that it was simple kernel recompile! Like I am the type who is going to recompile a kernel! Sheesh. Who does that anymore?”
*sigh*
Someone who considers himself a computer geek and Linux savvy and not only has he never compliled a kernel, but considers it a task too detailed and difficult to do.
*deep breath* *siiiiiiiiigh*

Links to sites where I got a lot of this information. Please note that I have been bumming around the web for a few hours now and I didn’t keep all of the links I visited. These are just the ones I wanted to keep around for future reference.

Wooledge
Bash Hackers
Linux Tutorial Blog*
*This one is older information (2008) and mostly the same information as the others, but I like this table. I even learned an option that I didn’t know existed before.

1) Using -x to check for my errors instead of spending $hours debugging a typo…
$ /bin/bash -x ./script_is_broke.sh

2) Using bash to increment for me.
a=1
##########
# REALLY old way of incrementing
a=`expr $a + 1`
# Old way of incrementing by one.
a=$((a+1))
# New way of incrementing by one.
let a++
##########
echo $a

3) Checking strings with built in test functions.
# Old way of checking strings.
if [ "$a" == '' ]; then echo True; else echo False; fi
# Second old way of checking strings.
if [ x"$a" == 'x' ]; then echo True; else echo False; fi
# New way of checking strings.
if [[ $a = '' ]]; then echo True; else echo False; fi
# or at least do
if [ test = "$a" ]; then echo True; else echo False; fi

4) Using bash parameter expansions more often instead of passing to awk or sed.
file="bash.pdf"
##########
# Old way to strip off extension.
basefile=`echo $file | sed -e 's/.pdf$//'`
# New way to strip off extension.
basefile=${file%.pdf}
##########
echo "$basefile"

More options for this can be found here:
http://mywiki.wooledge.org/BashGuide/Parameters#Parameter_Expansion

5) Using $(cmd) instead of `cmd`.
# Old way
variable=`cmd`
# New way
variable=$(cmd)

6) Passing stderr to a pipe
# Old way using file descriptors.
cmd_1 3>&1 1>&2 2>&3 | cmd_2
# New way.
$(cmd_1 >/dev/null) |& cmd_2

This is one that I am proud to have thought up on my own! I had been using that old method for years now (when I care more about capturing the errors then I do the output). As I read through the all the documentation I saw something that reminded me of this particular bit of nasty code. I thought about what I could do to improve it and I came up with this solution! I updated a bunch of my scripts and they are all working as the should!! 😀 I am so pleased. Then I Googled it.

Apparently I am not the only one to have come up with this solution…
*sigh*
Maybe next time when I come up with a great idea to reduce complex code I will actually be the first to do so… :-/

7) Matching strings with regular expressions!!*
* This Really Excites Me. Probably a bit too much which is why I am sure this will get me in trouble…
$ if [[ "This is a string" =~ ^Th.*rin. ]] ; then echo True; else echo False; fi
True

8 ) Totally guilty of one of the Bash Pitfalls found here: http://mywiki.wooledge.org/BashPitfalls
In fact, one of my scripts had a complex function to check that things had gone right and had created the directory in which the script was about to cd into before running commands. I have been meaning to go back and clean up that nasty code for a while, but it works so why break it unless I know I have the time to fix it? I am so ashamed for not having thought of this before. I blame the stressful job at the time…
# Old way
cd /foo; bar
# New way
cd /foo && bar
# Actually in my case it became
cd /foo && $( bar -options )

9) Start using $HOME instead of ~ in scripts
# Old way
cd ~
# New way
cd $HOME

10) Greping output of PS
# Old way
ps -elf | grep [g]edit
# New way
pgrep gedit

I still have a few pages to go through so I will be adding to this later.





Dropping Gnash in favor of Lightspark

20 08 2010

I was introduced to Lightspark today. Decided to give it a go and see how well it works. So far more things work then with gnash, especially all the little animated buttons idiots decide to put on their webpages (Really? Flash for a few buttons? What is wrong with you people?). Youtube starts to play, gets about 3 seconds into the video and freezes. Never managed to get sound with Youtube either. There are also a bunch of websites that have graphs and things for how many people showed up to their website in the past x days. Sometimes Lightspark shows them, sometimes it is just a dark grey box. Still, it is better then the white box with a black border I got with Gnash _all_the_time_everywhere_.

Overall, I think Lightspark is better the Gnash so far but we will see how long it lasts. I am still hoping for the ultimate demise and death of flash so it is nice that I have alternatives besides the that Adobe releases. I am still cruising around the web not really hampered by my lack of official flash support and youtube-dl is serving me well. Not ideal for grandma, but works for me.

If you want to check out lightspark, here is the wiki: http://en.wikipedia.org/wiki/Lightspark
Here is the sourceforge page: http://sourceforge.net/apps/trac/lightspark
And last, but not least, here is the launchpad page for the Debian and Ubuntu people: https://launchpad.net/lightspark

Lastly, as a side note. I have been running Debian Squeeze for something like a week now. WOW it is NICE! Major props Debian team!





Happy 17th Birthday Debian

16 08 2010

Happy Birthday Debian!

If anyone wants to send a word of thanks to a developer, they can do so here: http://thank.debian.net/

For anyone who has ever contributed to Debian, Thank you. My servers and desktops all run Debian Lenny. I am rocking Squeeze on my new desktop and loving it! Everyone is doing a fantastic job, keep up the great work!

From the bottom of my heart, Thanks Debian Team!