Yay KDE

http://www.kde.org/
https://fedoraproject.org/en/get-fedora-options

Fedora 19 + KDE = My favorite Linux setup.
I'm using it at work on my primary workstation as the primary OS.
I've got my co-programmer using it too as his primary OS on his workstation.
I've got my awesome Laptop running it (along with Steam and games).
And if I'd known more about it when I first set up my Grandmother's laptop I would have installed that instead of the Gnome version of Fedora.

It's not perfect but it's good.

- Chris

Android keyboard update

Just testing out the keyboard update. It's pretty good at figuring out what I mean. I only had to make one correction and only because I changed my mind about what to write. No more tap tap sound. One tap per word is better than one tap per letter. 

Apple Time Capsule and IP Problems

Stupid Apple Time Capsule keeps disappearing.

Turns out the IP being advertised over Bonjour is wrong and I have not figured out how to fix it.

I used a Linux system with avahi-tools installed

]# avahi-browse -a -r -t

=  wlan0 IPv4 User's Time Capsule                          Apple File Sharing   local
   hostname = [Users-Time-Capsule.local]
   address = [169.254.65.2]
   port = [548]
   txt = []
=  wlan0 IPv4 User's Time Capsule                          Microsoft Windows Network local
   hostname = [Users-Time-Capsule.local]
   address = [169.254.65.2]
   port = [445]
   txt = ["netbios=H=n"]
=  wlan0 IPv4 User's Time Capsule                          Apple TimeMachine    local
   hostname = [Users-Time-Capsule.local]
   address = [169.254.65.2]
   port = [9]

Well that's not right when the subnet is a 192.168.10.X
Checking the DHCP client table of the cable modem shows the capsule was given a valid address and I can even ping it. Still, the wrong address. The AirPort Utility can't greys it out since it can find it. Oh and it's connected to the router via Ethernet to rule out wifi issues.

Slow Snow Leopard and .local Domains in Active Directory and How I Fixed It

I had a very annoying problem with a Mac in an Active Directory domain. It's not completely solved but it's much better...

What you may wonder?
Well my Mac at work would hang for long periods of time any time I needed to authenticate like at the logon screen or to unlock a the screen saver or connect to a network share.

An important part of the problem is the domain is something.local so my mac is mac.something.local and the domain controller is dc.something.local.

I couldn't solve the problem completely but I do have a fairly satisfying workaround which could be fleshed out into a full fledged workaround.

Basically the mac when querying for dc.something.local would use mDNS and should to the subnet rather than asking the DNS server specified by DHCP.

In wireshark I'd see something like this.

Mac -> mDNS: Give me the A and AAAA record for dc.something.local
Mac -> correct DNS server: Give me the AAAA record for dc.something.local
DNS server -> Mac: No AAAA record for dc.something.local
wait....
timeout....
fail.

So Snow Leopard is being dumb and despite ipv6 being disabled and being given a DNS server to ask via DHCP, it's asking the wrong questions to the wrong places.

Solution? None found.
Workaround? Yes! I have a Linux server on the network and it happens to be running some old version of Fedora (these instruction should work on newer Fedora's and CentOS and RHEL's of the world) and the service called avahi-daemon installed.

That program talks mDNS and and reply. In a file called hosts in /etc/avahi I put in the following gems.

::ffff:0:192.168.1.2 dc.something.local
::ffff:0:192.168.1.100 mac.something.local
192.168.1.2 dc.something.local
192.168.1.100 mac.something.local

That has the nice effect of causing the mDNS requests to timeout immediately because it gets a reply to the AAAA request (it doesn't seem to matter that the ipv6 address isn't accessible because again I turned off ipv6). Also, it gets the ip4 address immediately and it can also resolve itself. (oh my mac is has a reserved ip in DHCP so this works for me) I can even get my Kerberos tickets nearly instantly.

I have another file server though and connections take a day and a half too... or at least they did.
I just added


::ffff:0:192.168.1.3 filesrv.something.local
192.168.1.3 filesrv.something.local


And boom, fast connection times.

Wishlist for the internet time. I would really like someone to write a program that would listen to for mDNS requests in a given something.local domain and query the answer via the normal unicast DNS server and then reply over mDNS with the real answer and the fake ipv6 answer so it will work for any given host on my network. Bonus points if it's safe enough to run right on the DNS server (which in this case is the Windows Domain Controller) so I don't need a third party to the DNS conversations.

Nexus 10

It's pretty awesome.

Erase (Discard) all data on an SSD in Linux

A little background:
I had a 60 GB OCZ SSD that had Windows on it and some apps. I wanted to erase it to start fresh to test out Fedora 18 Alpha on it in a laptop. I didn't need to securely erase anything, I just wanted the SSD to know it can erase everything.


Here's what I did.

First I had a Fedora LiveUSB drive. That's not important but what is important is hdparm installed. I had to yum install hdparm from a terminal. Single user runlevel is a good idea for the rest of this...

First I needed to see how large the SSD is in sectors.
gdisk told me what what I wanted to know.

(The following is retyped, not copy and pasted and parts are omitted)

gdisk /dev/sda
Command (? for help): p
Disk /dev/sda: 117231408 sectors

So now know the size, 117231408 sectors which is important because hdparm will need input in sectors.

I found out that the --trim-sector-ranges option of hdparm will not do more than 65535 sectors at a time so I needed to use --trim-sector-ranges-stdin so I could specify all at once.

First I needed to generate a sector list.

for ((i = 0; $i < 117231408; i = $i + 65535)) do echo $i:65535 >> sectors.txt; done

Warning about that, I typed that from memory. The important part is you're looping from Sector 0 up untill the end before 11723140 (for my drive). Then it's stepping by 65535. I feel like I should have stepped by 65536 but I didn't so each line might have overlapped by 1 sector. In practice it wasn't an issue. Also, the very last entry in sectors.txt will be wrong. I didn't care enough to special case it or manually calculate the correct length.

So now sectors.txt looks like
0:65535
65535:65535
131070:65535
...

Then I did the actual (well nearly the actual) trim command.

hdparm --trim-sector-ranges-stdin /dev/sda < sectors.txt

Actually there's another --option thing but it will tell you and warn you what you're about to do is dangerous to your data. I'll omit it for the people copy and pasting to make the stop and think.

I ended up getting an error about a few of the sectors at the end (the error on the last entry basically) but nothing bad. Rebooting is now a good idea. And you're done!

If you follow these instructions be warned I might be doing it wrong and I only looked at about the first 1K of data on the drive to see it was blanked.

Good luck.

Dell PERC 5/e on Fedora 16 and an MD1000 Enclosure

For various reasons I have a Dell PERC 5/e hooked up to an MD1000 enclosure on a workstation running Fedora 16 64 bit. All is fine with the already configured raid but I can't edit it at all when I add or remove drives. For a long time I lacked a way to edit arrays without rebooting to bios.

Now no more.

Thanks to the following links:

Download link for MegaCli: http://www.lsi.com/downloads/Public/Obsolete/Obsolete%20Common%20Files/4.00.16_Linux_MegaCli.zip

Ah-ha moment link (a.k.a how to make it work): http://www.kattare.com/docs/faq_view/1532/how-can-i-setup-megacli-on-my-64-bit-ubuntu-11-04-or-12-04.html

How to use it: http://tools.rapidsoft.de/perc/perc-cheat-sheet.html

So first download the zip, unzip the zip, unzip the zip that was in the zip, yum localinstall the rpm and you're done installing. You'll find the program in /opt/MegaRAID/MegaCli/

Now for the magic to make it work, lets make a shell script wrapper. It's not mandatory but it's a good idea. Just look at the ah-ha moment's link about 2/3rds down the page right after the part where they "Test it out..." Actually, just read the whole page. In case that's down the magic is that the program checks the kernel version and only runs on 2.6.
setarch x86_64 --uname-2.6 /opt/MegaRAID/MegaCli/MegaCli64
Will make it work. The script sticks all that in a wrapper for less typing.