The Super Dimensional Fortress

A title like that suggests something between a B17 bomber (the “flying fortress”) and Superman’s hideout (” fortress of solitude “). Well this isn’t either, but it is pretty cool none the less. In talking about sdf.org, a group of 8+ enterprise servers running Unix that collectively make a super computing center that is freely available to the public for use.

There are some paid perks as well, but any user can sign up for a free account and get an ssh login to a private online account, complete with storage space, an email address, your own website URL (you have to create the website yourself, but they host it for you) and access to online games, old school “bboard” bulletin board coms, irc, and more!

With very reasonable one time or annual rates, you can also get DNS, server hosting, mailbox hosting, and other cool goodies. They also service dial up internet for a really reasonable rate (I think it is around $10/month). Certainly worth taking a look if you are at all geeky.

They boast around 40000 active users, so it looks like there are plenty of folks to chat or online game with. It is focused on sharing knowledge and generally helping educate people about technical things, as well as provide a means of access to services that might not be available elsewhere based on a users remote location. Most everything is designed around the terminal, since you log in via ssh, but paid memberships can also use some x11 services, which is pretty neat.

Their mission statement and a brief summary:

[01] WHAT IS SDF?  (QUICK SUMMARY)

Welcome to the only all 64bit public access supercomputing center!

The Super Dimension Fortress is a networked community of free software
authors, teachers, students, researchers, hobbyists, enthusiasts and
the blind. It is operated as a federally recognised non-profit 501(c)7
and is supported by its members.

Our mission is to provide remotely accessible computing facilities for
the advancement of public education, cultural enrichment, scientific
research and recreation. Members can interact electronically with each
other regardless of their location using passive or interactive forums.
Further purposes include the recreational exchange of information
concerning the Liberal and Fine Arts.

Members have access to games, email, usenet, chat, bboard, gopherspace,
webspace, programming utilities, archivers, browsers, and more. The SDF
community is made up of caring, highly skilled people who operate behind
the scenes and in the underground to maintain a non-commercial INTERNET.

While we did initially start out on a single computer in 1987, the
SDF is now a network of 8 64bit enterprise class servers running
NetBSD realising a combined processing power of over 21.1 GFLOPS!

Our mass storage configuration is comprised of 60 spindles of mostly
36.4gb and a few 9.1gb SCA LVD SCSI drives using DIGITAL Storage Works
hotswap disk arrays. We have roughly 2 terabytes of storage online.

We are networked via two sprintlink T1s and a T1 to savvis. We do BGP
peering and try out best to load balance between the links via a CISCO
7xxx router/switch. We are using a 'swamp' class C 192.94.73 which has
basically been assigned to our site admin along with his class C back
when you could request one from the INTERNIC without much fuss.

The userbase is comprised of two major user groups: USERS and ARPA

'user' accounts are free and offer many features.
'arpa' accounts are permanent members and can vote on SDF features.

Supplemental ARPA privilidges include:

MetaARPA ('trusted' member privs (cron, tcp port forwarding))
TWEAK (tweakable and additional disk quota)
VPM (Virtual POP3 mailboxes)
DNS (Domain Name Service)
DBA (MySQL database access)
VHOST (Virtual Web hosting - includes VPM, DNS and DBA)
SERVER (Server process (mud, nameserver, et cetera))
MDNS (Dynamic DNS)
MLIST (Mailing List service)
DIALUP (over 10,000 numbers in the USA + Canada)

Sponsorship information can be found on our website or in the FAQ.

Bottom line: a super geek club that is super fun, even for those who are not super technically savvy. However, an above average computer skilset is required to make use of this system, one should at a minimum know how to use ssh. So head over to sdf.org and check it out!

Linux – keep it simple.

Advertisements

Porting Debian Linux to your cell phone part 3 of 3

If you are still with me, then you have already set up your phone to first boot Debian Linux, and then Linux will start Android in a chroot environment. Your phone is actually already running Debian Linux, just with Android being run and displayed on the screen. At any moment, you can actually stop or kill Android. At this point, you also have the power to mess Andriod up, so do be careful!

If you just tuned in, I recommend that you go back to the 1 of 3 for this post, as there is a lot of critical information you need.

Right now, you can SSH into your own Linux from the Android gui by using any ssh app to yourself as the local host, since our SSH deamon is running. What we want, though, is for your screen to display the Linux screen, instead of the Android that is running in a chroot environment.

A key part of all of this, is that Android, other than through services like SSH, does not know that Debian Linux exists and it does not have any control over the Linux system or functions. One problem with this is that Android may occaisionally crash due to memory problems, if your Linux environment is using too much RAM. Ironically, if you SSH into your Linux environment, you can use ps aux, or top to see all of Android’s running processes. Your Linux environment is now the ultimate root, because even Android doesn’t know it exists. You can log anything from Android and save it, you can stop any Android process. You have complete control over your Android system.

However, before making the “plunge” to a Linux only phone, you need a few details. The easiest way to get these is to do some research on your phone. Through SSH, run the ls command in your /dev folder, and look for “input”

[CODE]
$ cd /dev
$ ls |grep input

/dev/input
/dev/input/event7
/dev/input/event6
/dev/input/event5
/dev/input/event4
/dev/input/event3
/dev/input/event1
/dev/input/event0
/dev/input/event2
[/CODE]

On my Samsung Captivate Glide, these are all the available inputs. But what are they? Well, there are several tools to check this. The easiest way, however, is to SSH into Linux, start x11vnc in Linux, and use an app like bvncfree in Android to bring up a visual screen to work with. How you need to do this is a bit tough to describe, because it is so dependent upon your phone and setup. However, if you are using my files, the user trondroid should have a shell script in the home folder for starting jwm in this fashion.

Another way is to start the XserverXDSL app in Android, and then startx in Linux through SSH. That should get you to the same place.

Either way, you should see something similar to this (although this screenshot was taken when I was using Debian Squeeze, rather than the new files, which are Debian Jessie) :

phone

Once you have established a “visual” screen, you now should open up a terminal in your Linux screen. Remember, all input commands that you input right now are from the Android app you are using. That means the “mouse”, “click”, and “keyboard” are all virtual. You need to set up your real screen as a mouse, for motion and clicking. You also need to set up your physical buttons from your phone, and your keyboard if you have one. With your terminal open, use evtest, like so:

[CODE]
$ sudo evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0: STMPE_keypad
/dev/input/event1: mpu-accel
/dev/input/event2: sec_key
/dev/input/event3: sec_touchscreen
/dev/input/event4: proximity_sensor
/dev/input/event5: light_sensor
/dev/input/event6: HALL
/dev/input/event7: sec_touchkey
/dev/input/event8: compass_sensor
[/CODE]

This even works on your home computer. For instance, here is my laptop:

[CODE]
$ sudo evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0: Sleep Button
/dev/input/event1: Lid Switch
/dev/input/event2: Power Button
/dev/input/event3: AT Translated Set 2 keyboard
/dev/input/event4: Logitech USB Optical Mouse
/dev/input/event5: SynPS/2 Synaptics TouchPad
/dev/input/event6: Video Bus
/dev/input/event7: ST LIS3LV02DL Accelerometer
/dev/input/event8: HDA ATI SB Mic
/dev/input/event9: HDA ATI SB Line
/dev/input/event10: HDA ATI SB Headphone
/dev/input/event11: HP WMI hotkeys
Select the device event number [0-11]:
[/CODE]

But we will focus on the phone. Great! Now we know what event is what input! For instance, event3 is the touchscreen. Now we have something to work with. In my case, event0 is the physical keyboard, but those are rare these days.

You can also test those inputs, by choosing a number for the device, and then using that function. Here you can see me test the “menu key” on the keyboard:

[CODE]
Menu Key on keyboard
Event: time 25170.575766, type 4 (EV_MSC), code 4 (MSC_SCAN), value 8b
Event: time 25170.575844, type 1 (EV_KEY), code 139 (KEY_MENU), value 0
Event: time 25170.575854, ————– EV_SYN ————
[/CODE]

Another great tool is called xev, again, open up a terminal and use it like this:

[CODE]
$ xev

ButtonRelease event, serial 33, synthetic NO, window 0x1e00001,
root 0x26f, subw 0x0, time 156984900, (175,123), root:(228,195),
state 0x100, button 1, same_screen YES

MotionNotify event, serial 33, synthetic NO, window 0x1e00001,
root 0x26f, subw 0x0, time 156985076, (177,123), root:(230,195),
state 0x0, is_hint 0, same_screen YES
[/CODE]

There is also xinput, here is an output from my computer:

[CODE]
$ xinput test-xi2
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Logitech USB Optical Mouse id=9 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad id=11 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Video Bus id=7 [slave keyboard (3)]
↳ Sleep Button id=8 [slave keyboard (3)]
↳ AT Translated Set 2 keyboard id=10 [slave keyboard (3)]
↳ HP WMI hotkeys id=12 [slave keyboard (3)]
EVENT type 13 (RawKeyPress)
device: 3 (10)
detail: 54
valuators:

cEVENT type 14 (RawKeyRelease)
device: 3 (10)
detail: 54
valuators:

EVENT type 13 (RawKeyPress)
device: 3 (10)
detail: 40
valuators:
[/CODE]

The overall idea, though, is that you need to open up an x session, so you can then see what x inputs are matched to which event. Once you have all of this information, you can edit the /etc/X11/xorg.conf file to match. Here is the one I made for the Samsung Captivate Glide:

[CODE]
Section “ServerLayout”
Identifier “Layout0”
Screen “Screen0”
InputDevice “touchscreen” “CorePointer”
InputDevice “keyboard”
InputDevice “mediakeys”
InputDevice “frontkeys”
EndSection

Section “Monitor”
Identifier “Monitor0”
ModelName “Monitor Model”
DisplaySize 800 480
EndSection

Section “InputDevice”
Identifier “touchscreen”
Driver “evdrv”
Option “Device” “/dev/input/event3”
Driver “multitouch”
EndSection

Section “InputDevice”
Identifier “keyboard”
Driver “evdev”
Option “Device” “/dev/input/event0”
Option “CoreKeyboard”
Option “XkbRules” “xorg”
Option “XkbModel” “pc105”
Option “XkbLayout” “us”
EndSection

Section “InputDevice”
Identifier “keyboard”
Driver “evdev”
Option “Device” “/dev/input/event8”
Option “XkbRules” “xorg”
Option “XkbModel” “pc105”
Option “XkbLayout” “us”
EndSection

Section “InputDevice”
Identifier “mediakeys”
Driver “evdev”
Option “Device” “/dev/input/event2”
EndSection

Section “InputDevice”
Identifier “frontkeys”
Driver “evdev”
Option “Device” “/dev/input/event7”
EndSection

Section “Device”
Identifier “Card0”
Driver “fbdev”
Option “fbdev” “/dev/graphics/fb0”
Option “Rotate” “left”
Option “VertRefresh” “60”
EndSection

Section “Screen”
Identifier “Screen0”
Device “Card0”
DefaultDepth 16
SubSection “Display”
Depth 16
EndSubSection
EndSection
[/CODE]

Notice how you must declare a screen, a monitor, and then the card that controls it. /dev/graphics/fb0 is the framebuffer that you got the other day, if you were following along with these posts. You will also notice, that for each section, a driver is declared. The drivers used here are generic drivers. You may have different hardware, and use different drivers. So, if one doesn’t work, google the xorg.conf section and the word drivers to see some of the different drivers available. You may even need proprietary drivers specific for your device. Like I said though, these generic drivers worked great for me. So I would try those first.

Once you have your drivers and xorg.conf file all set, it is time to take the plung. Be sure to back up your system first. Remember, TWRP or CWM are your freinds, as they work outside of all of the other work you are doing. So you can always start over or go back to something else.

Now, go back to your /etc/rc.local file. It should say:

[CODE]
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will “exit 0” on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

# Start the ssh client, in the event you need it.
/etc/init.d/hostname.sh start
/etc/init.d/ssh start

# Clean up bad crash before starting x server.
# /sbin/busybox mkdir -p /tmp/.X11-unix/remove
# /sbin/busybox rmdir /tmp/.X11-unix/remove
# /sbin/busybox rmdir /tmp/.X11-unix/

# Start the x server, warning, if the touchscreen or keypad doesn’t work
# then you cannot escape without killing power!
#/usr/bin/startx &
#export USER=root
#vncserver :5000

exit 0
[/CODE]

And change the last part to say this:

[CODE]
# Start the x server, warning, if the touchscreen or keypad doesn’t work
# then you cannot escape without killing power!
/usr/bin/startx &
#export USER=root
#vncserver :5000

exit 0
[/CODE]

Now you have told it to startx on the next startup. If all goes well, reboot your phone, and you should see the XFCE desktop. If not, then you need to figure out how to edit the xorg.conf file to make it work right. You may also need to uncomment the lines about rmdir /tmp/.X11-unix, and the other lines like it, if your xserver ever crashes.

I have noticed several variants, especially on Android 4.4 and newer, that it will startx, but also start Android. You will see one normally, and then a small, pink version of the other overlayed on part of the screen. Almost like a picture in picture TV, but very dificult to understand or use. In these cases, you may need to add a command to kill surfaceflinger, or stop zygote to get Android to “clear out”. You actually could just skip Android altogether, but having the chrooted Android is great for playing with making phone calls, etc, as I do not know how to do that from Linux yet.

If you made this work then you do have some pretty good Linux skills, if I may be so bold. This is not an easy task, and not for the faint of heart. So great job! Now it is up to you to improve upon this and make it useful. Who knows, you might be giving Ubuntu Touch a run for the money!

Linux – keep it simple.

 

AndFTP and JuiceSSH

I would like to start off by stating the obvious. I am not an app expert. I am not an SSH expert. I am a simple guy who just needs simple, functional tools. In this case, both of these tools were well crafted by their designers, and have become indispensable tools to me in my trade.

When it comes to SSH sessions run on the go from my phone, using the onscreen keyboard, JuiceSSH is my go to app. The interface is very slick and user friendly. The font and colors are easy to read, and I love that tapping on the screen brings up the special key bar. This bar has all the regulars, like CTRL, TAB, |, etc., and really comes in handy. The screen rotation works, with scaling, so it will keep everything in view. I like it so much in fact, that it is the only app I use for SSH sessions. Except when I need to download or upload something via SCP.

SCP is of course secure copy, the ability to use the cp (copy) command over SSH to upload or download a file. Obviously, there are better ways to move files, such as SFTP. In some cases, however, it is not feasible because the server in question isn’t set up for that. As long as you can SSH to a Linux server, then you can use SCP to transfer files back and forth.

Thus enter AndFTP. This is the handiest SCP tool I have found for Android! Believe me, I’ve tried several. VX ConnectBot, for instance, does SCP file transfers, but you have to hand type the files FULL path to upload or download. That gets pretty tedious when the path is something like:

/home/alaskalinuxuser/Documents/projects/phones/compile/omni5/external/libgsm/src/rpe.c

So it is much easier to use a tool such as AndFTP. It does all of the typing for you, and presents a graphical browser interface for you to work with. While it still isn’t drag and drop, it sure is handier than typing! The interface has you select files, and then press the upload/download button at the top of the screen. Clicking on a folder opens it, and pressing the “..” buttons at the top of each directory moves you up a level in the folder tree. At the bottom of the screen, you can see it send text commands to the server. Pretty handy for a simple fellow like me.

Linux – Keep it simple.

How to make XRDP look better

One of the things I do on a regular basis is use rdesktop to log into another computer (or cell phone) through xrdp. It is simple and works very well, as well as being very simple to set up. While not really a problem, I got bored of looking at the old xrdp icon and the simple xrdp logo for the interface. So, I decided to change it.

Unfortunately, I didn’t know where that was done. I checked the xrdp.ini file, but it didn’t have any reference to the pictures used. A quick Google search led me to look in the /usr/local/share/xrdp folder. However, that folder didn’t exist in Debian. The article was for a RedHat/Fedora user, so I figured they just have a slightly different folder set up.

The article said that xrdp used bitmap files, so I just tried to look it up with locate and grep:

$ locate xrdp |grep bmp
/usr/share/xrdp/ad24b.bmp
/usr/share/xrdp/ad256.bmp
/usr/share/xrdp/xrdp24b.bmp
/usr/share/xrdp/xrdp256.bmp

When I opened that folder I could see that those files were in fact the icon and logo displayed during log in. While I still don’t know what points to these files, I decided to cheat and just change these files with my own. I used image magic to convert my files for my pictures, then copied them to the folder and renamed them.

$convert theme_tron.png tron.bmp
$convert android.jpg bg.bmp
$sudo cp bg.bmp /usr/share/xrdp/ad256.bmp
$sudo cp tron.bmp /usr/share/xrdp/xrdp256.bmp
$sudo convert /usr/share/xrdp/ad256.bmp -resize 25% /usr/share/xrdp/ad24b.bmp
$sudo convert /usr/share/xrdp/xrdp256.bmp -resize 25% /usr/share/xrdp/xrdp24b.bmp

Now when I log in, I get to see my custom login screen!

Linux – keep it simple.