chebe: (Wild)
I spent way too long trying to build a solution out of parts I had readily available before I discovered that Adafruit had exactly the thing I needed: the piOLED, tiny screen to attach to my Raspberry Pi Zero W. One of the examples even included what I was after; a way to display the ip address, in

The script doesn't exit as cleanly as I'd like, so the first thing is to put the while True: loop into a try: and put the cleanup in the catch:
except KeyboardInterrupt:

The tutorial also has instructions on how to run the script on startup; by putting it in rc.local
sudo vim /etc/rc.local
And add the call to the script, before exit 0, pushing it into the background;
sudo python /home/pi/Adafruit_Python_SSD1306/examples/ &
Save and exit.

Cool, now we have a way to display the ip address of the pi so we can ssh in. But, there is nothing to turn it off again.

First thing needed is a python script to blank the screen. You can take a copy of and strip out everything except the setup code and the cleanup code. Cool, this works, kinda. It clears for a moment and then starts displaying again. This is because we haven't killed the processes doing that yet.

So, we write a script to do that. (Here I ran into some dash versus bash problems. Damn you dash, damn you.)
Something like;

pids=$(ps -ef | grep 'python .*examples/' | awk '{print $2}')

echo $pids | while read -r line;
    sudo kill -9 $line

sudo python /home/pi/Adafruit_Python_SSD1306/examples/

Great, this works wonderfully, when we manually invoke it. We're going to want it to run at shutdown too though. (Because, while power is still supplied to the pi, even though it's off, and the screen isn't updating, the old data is still displaying.)

This is not as easy as it should be. I basically wanted a rc-local for shutting down. I'm not the only person who has had this idea, so have a look here for a way to add shutdown functionality to rc-local.

* Copy /etc/rc.local to /etc/rc.local.stop
* Edit /etc/init.d/rc.local, adding in extra info to # Required-Stop:, # Default-Stop:, edit the case statement to call do_stop in event of stop), and add the do_stop function (which is a copy of the do_start function changed to point at rc.local.stop).
* Delete the old rc-local daemon; sudo update-rc.d -f rc.local remove
* Pick up the new; sudo update-rc.d rc.local defaults

But, this alone isn't enough for Debian/Raspbian to pick up the changes. Enter systemd.
sudo vim /lib/systemd/system/rc-local.service
And add this line just after ExecStart;
ExecStop=/etc/rc.local.stop stop
Save and exit.

Now, stop the daemon, reload it, and then start it.
sudo systemctl stop rc-local
sudo systemctl daemon-reload
sudo systemctl start rc-local

One final thing, edit rc.local.stop to use the stop script instead of the start one. And don't push it to the background. Something like;
sudo /home/pi/Adafruit_Python_SSD1306/examples/

Finally, when you reboot, startup, and all the other fun things the screen should behave nicely. Enjoy.
chebe: (AsciiC)
Okay. Hi. Yes, I'm still here. It's been an eventful err, many months. But more about that another time. Maybe.

Well, either that, or, I only post once in a Blue Moon! (Sorry, couldn't resist.)

Last year at EMF I picked up a BeagleBone Black (rev C). This week I actually unpacked it and powered it up. I was pleasantly surprised to find that the rev C ships with Debian installed, but that means most of the documentation online (and on the BBB) is slightly out of date. No worries; things are actually simpler now!

Even though it shipped with Debian when I tried to apt-get update/upgrade/install I got errors. So there was only one thing for it; flash the onboard memory. When I went about this I found that the source of online documentation was (is?) offline. And the wayback machine was only serving up some too-old files. Luckily I found a chap with a link to the most recent eMMC flasher image! I've said it before, and I'll say it again, yay for bloggers!

One thing that tripped me up; when writing the image to the SD card, on Windows you need to run the program As Administrator for sufficient privileges. Learn from my mistakes friends. Also, only hold down the SD button until the 4-LEDs start to flash, then let go. The rest is smooth sailing.

When you boot up, you ssh in (over the USB cable); as root, with no password. Set one immediately! Then you do all the usual configuration things;
set a nice hostname - vim /etc/hostnames, vim /etc/hosts
add a non-root user - adduser, visudo
setup wireless - vim /etc/network/interfaces (unfortunately it involves hardcoding your password)

(I got a raspberry pi wireless dongle to use with my cubox, and now my BBB. Poor thing has never meet a raspberry pi. ... Speaking of the cubox; arch linux turned out to be just too much effort. Will probably throw Debian on there as well.)

Then reboot, and if ifconfig doesn't show an ip-address try ifup wlan0. Once online apt-get update, apt-get upgrade. And just like that you have a fully functioning Debian server (with broken out physical pins) to bend to your will. I have to say, it is one of the easiest setups I have encountered with microcontrollers/embedded systems. And a good first impression means a lot. I look forward to playing with it more.

*edit 2015-09-16*
Setting up my second BBB was far more troublesome! I finally got it working; using dd in linux, onto an 8gb micro sdcard (my 4gb must have a .1 or .2 too small), and even though the file (from here) is named 2015-03-01 the installation reports 2015-07-17. Curiouser and curiouser.

New Gadget; CuBox

2014-Jun-30, Monday 08:35 pm
chebe: (AsciiC)
I've always wanted my own server. Although I haven't exactly had much need for one. Then I heard about these little beauties; the CuBox (or rather one with the older chipset). For some scale here it is next to a 250ml teapot and a one-Euro coin.

CuBox next to a 250ml glass teapot and one-Euro coin

Just too cute
Photo by chebe

It arrived with Ubuntu (10.04!) installed, which would just not do. So I copied all the cool kids and installed Arch linux on it. For that extra-low-level feel. I actually used the CuBox installer, which was very simple to use. But Arch is very stripped down, so I then had the fun of installing all the things I normally take for granted. Like vim, and sudo. Though to be fair, once I figured out that the package manager was called pacman, and an update is just pacman -Syu, things got much easier.

I've configured it up as a DNS server, and installed this dotey USB wifi dongle. So now it can sit happily next to the power socket (all the other cables unplugged), and I can ssh in to it. I'm still not sure what, if anything, I need it for, but at the very least I'm going to play around with mongodb and django for a bit.
chebe: (DarkStare)
"Why do you still care about dual booting? Why don't you just run everything in a VM?"

I gave it a go, I really did. Created a Ubuntu 1110 vm in VirtualBox. Fixed storage size, everything was going well enough. (Ubuntu has a problem with my wireless card, but that's almost traditional at this point.) I was using it for college work so I needed stability and didn't upgrade for a while. Too long it seems. When I went to upgrade the repos had vanished, and for added benefit, the vm lost the ability to use any network connection.

I noticed VirtualBox had an update, and thought, maybe they'll have better drivers. But instead the vm wouldn't even start. I attempted to mount the .vdi filesystem. Discovered the way I knew only worked with Windows vms, but found another method using guestmount. So I mount with guestmount, but seemingly my /home no longer exists!

Frustrated I try running the vm again, and for some unknown reason it actually starts, but the graphics crash and die leaving me with a text-only terminal. Grand, as soon as I remembered my password. I log in, and right there is my /home! I quickly copy everything to a previously set-up shared folder in the host, and exit.

VirtualBox says there's another update available. So I update, and now the vm won't run again, giving me error messages about something disabled in the BIOS. I should have known better.

And this is just another reason why I dislike virtual machines. (And before you start, it's not just VirtualBox, I've had even more problems with VMWare.)
chebe: (HandAgainstGlass)
I bought a touchatag ages ago, but couldn't get it installed properly under linux (and when I got it working under Windows the supplied software required that I create an account, which I really dislike). It's no longer available to purchase (except perhaps through resellers with old stock), but it is a RFID-tag reader (that came with a few RFID-tags) and was part of the 'Internet-of-Things' effort. Although anyone I know who has one didn't get it for that reason. It lay gathering dust in the back of my mind until I suddenly had a project idea. But first, I had to get the darned thing to work!

Here's how I went about it under Fedora 18.

Pre-requisites (you probably don't need all these, but I have ambitions);
yum install pcsc-*
yum install libusb libusb-devel
yum install libnfc*

Install the driver;
cd ACR122_Driver_Lnx_Mac10.5_10.6_10.7_104_P/
tar -jxvf acsccid-1.0.4.tar.bz2
cd acsccid-1.0.4/

Check it's working;
Lists it as Advanced Card Systems, Ltd.

It should list your reader, if not, try pcsc_scan, if still no luck run pcscd -f.
If at this point it's complaining that your firmware is bogus you need to edit the config file to skip the version checking, for me the file path is;
vim /usr/lib64/pcsc/drivers/ifd-ccid.bundle/Contents/Info.plist

Locate "ifdDriverOptions" and turn the "0x0000" value into 0x0005 (0x0004 might work too). Save and exit, then restart the daemon. I had trouble getting it back up again, so I rebooted.

Run the checks again to see that it is now picking up the device properly.

Use it;
This varies greatly depending on what you want to do. One of the alternatives recommended on the touchatag site is iotope. I downloaded it (to run in standalone node mode), unzipped, and ran the bash script provided (it's Java based). Then you open a browser and go to http://localhost:4242/ui/. Then simply put a RFID-tag in the reader and (if compatible) see the details show up.

I pieced together this information from two sources;
1. An archlinux wiki page which suggests another application, and
2. A backtrack linux page that suggests an entirely different application and use.

This is probably old-hat to those of you it interests, but I've finally gotten it to work, so I'm putting it here against my forgetting in future.
chebe: (AsciiC)
I got a Huawei E173 internet dongle today, and was surprised to find that only Windows and MacOS were supported (I'm not sure why, maybe I just haven't bought any new tech in a long time). But I persevered.

Fedora 15 & 16;
Plug in device, and NetworkManager will (after a while) automatically pick it up. Turn on 'Mobile Broadband', click on the clickable option below it and you'll be brought through the wizard (insert PIN, select provider, plan type (i.e. contract or prepay), etc). Done.

Fedora 14;
Not so easy. Plug in device and it's only getting picked up as removable storage.
You need two packages from the official repos; libusb-devel and usb_modeswitch
Once installed the device gets picked up properly by NetworkManager. Select it from the 'Mobile Broadband' section and go through the wizard. Done.

All in all, not too bad. And actually faster than installing the .exe under Windows 7. (Note, the Ubuntu package names seem to be libusb-dev and usb-modeswitch.)
chebe: (Teddy)
I've dual-booted my laptop (netbook strictly) with Ubuntu 11.04 and Fedora 15 (in the end I just erased the new F15 installation mentioned previously and installed 11.04 first, then gparted before F15). And having used them both for a little while feel the need to vent.

My issues )

Both are good, neither are great. I want to keep parts of both, and to abandon parts of both. I would be interested in hearing other peoples experiences of these distros, as well on hints on how to fix/improve my experience. (*Note* Replies like 'use debian' will not meet with a warm reception.)
chebe: (StormyThoughts)
This post is brought to you by the need to write down what I did, so I can figure out how to fix it in the morning. Follow it at your peril.

There are a few things I really dislike in the land of linux, and LVM on a single-disc laptop is high on the list. Mostly because I don't really know how to use it.

Motivation; There seems to be something very wrong with libusb on Fedora 15, but, and it hurts me to say this, it is just fine on Ubuntu 11.04. So I wanted to shrink my Fedora installation and dual-boot with Ubuntu. Sounds easy, doesn't it?

(Half-way through I remembered that I'd made a note to myself to always install Ubuntu first in these circumstances, but, well, that wasn't an option. So, into the tangled depths of LVM went I.)

gparted doesn't work with lvm, this made me sad. Figuring I had to fight fire with fire I downloaded the Fedora 15 Live CD. Boot into it, yum install system-config-lvm. Start system-config-lvm and resize home and root volumes to free up space. But things are looking a bit fragmented, won't be able to shrink size of VolGroup with things like this. So, make a new lv, exact same size as root, but contiguous with the other lvs. From command line, load up lvs and copy;
lvm vgchange -a y
dd if=/dev/VolGroup/lv-root of=/dev/VolGroup/lv-root2 bs=4M

Then go back into system-config-lvm, rename lv-root as lv-root-orig, and lv-root2 as lv-root. Then remove lv-root-orig (and any snapshots related to it).

Now all the data is on the left of the physical volume, and the empty space on the right. From command line;
lvm vgchange -a y
pvresize --setphysicalvolumesize 100G /dev/sda2

Done. Boot back into hard-drive, everything still works, but there's a missing 50GB that's not showing up. Not in system-config-lvm, not in disc utilities, not in gparted. Oops. The lvm aware tools say it's not in the VolGroup, don't see it at all. The lvm unaware tools say the VolGroup still takes up the entire disc. What to do? *scratches head*


nmap scripting engine

2011-Apr-27, Wednesday 11:38 am
chebe: (GoldenMask)
You know nmap? It's a really helpful tool for auditing your networks, and probing your machines to check for vulnerabilities.

Aside: you should only ever use this on your own network, or one on which you have the permission of the administrator. Not everyone minds a little exploration, but you don't want to annoy the wrong people. In case you don't happen to have a network handy, nmap provides so you can try out all but the most aggressive techniques.

I'm not going to go into a lot of detail here, so if you're interested there is info in the man pages, on the nmap website, and there is even an nmap book. Here are some very basic commands;

Host Discovery;
details )

Port Scanning;
details )

Service Version and OS Detection;
details )

juicy details )

On a related note; are you running BackTrack in VirtualBox, have enabled the network connections and everything, but still no internet? Try;
/etc/init.d/networking restart
When complete check ifconfig. I found my wireless connection hiding in eth1!

They say a little knowledge is a dangerous thing. Let's prove them wrong.
chebe: (BluesBros)
I do love Creative music players. What I do not love is the Windows-only nature of their software. Luckily there have always been programmers willing to spend time getting MTP devices to work under linux, however clunkily.

But I got a new player recently, and was surprised to find that it's not MTP. It's just a regular mass storage media device. Which means it can be used with regular music software like banshee and rythmbox, with one small tweak.

Props to the author of this snippet.

Plug in, mount device, touch .is_audio_player (or otherwise create empty file with this name) in the root of the devices file structure (e.g. /media/My Zen/), unmount and disconnect device. Start your music software and reconnect device. It should appear automagically. And this should work for any kind of mass storage media device.
Page generated 2017-Oct-23, Monday 05:02 pm
Powered by Dreamwidth Studios