X-Git-Url: https://pere.pagekite.me/gitweb/homepage.git/blobdiff_plain/3ef50e8eb2ff0974c5f5f68fa1b0275fd2143f8e..79941f6fd9b2b734be3f403a9190841032ec66f7:/blog/index.rss diff --git a/blog/index.rss b/blog/index.rss index 5b975768ba..9580a6a0fe 100644 --- a/blog/index.rss +++ b/blog/index.rss @@ -6,6 +6,63 @@ http://people.skolelinux.org/pere/blog/ + + My first perl GUI application - controlling a Spykee robot + http://people.skolelinux.org/pere/blog/My_first_perl_GUI_application___controlling_a_Spykee_robot.html + http://people.skolelinux.org/pere/blog/My_first_perl_GUI_application___controlling_a_Spykee_robot.html + Wed, 1 Sep 2010 21:00:00 +0200 + +<p>This evening I made my first Perl GUI application. The last few +days I have worked on a Perl module for controlling my recently +aquired Spykee robots, and the module is now getting complete enought +that it is possible to use it to control the robot driving at least. +It was now time to figure out how to use it to create some GUI to +allow me to drive the robot around. I picked PerlQt as I have had +positive experiences with the Qt API before, and spent a few minutes +browsing the web for examples. Using Qt Designer seemed like a short +cut, so I ended up writing the perl GUI using Qt Designer and +compiling it into a perl program using the puic program from +libqt-perl. Nothing fancy yet, but it got buttons to connect and +drive around.</p> + +<p>The perl module I have written provide a object oriented API for +controlling the robot. Here is an small example on how to use it:</p> + +<p><pre> +use Spykee; +Spykee::discover(sub {$robot{$_[0]} = $_[1]}); +my $host = (keys %robot)[0]; +my $spykee = Spykee->new(); +$spykee->contact($host, "admin", "admin"); +$spykee->left(); +sleep 2; +$spykee->right(); +sleep 2; +$spykee->forward(); +sleep 2; +$spykee->back(); +sleep 2; +$spykee->stop(); +</pre></p> + +<p>Thanks to the release of the source of the robot firmware, I could +peek into the implementation at the other end to figure out how to +implement the protocol used by the robot. I've implemented several of +the commands the robot understand, but is still missing the camera +support to make it possible to control the robot from remote. First I +want to implement support for uploading new firmware and configuring +the wireless network, to make it possible to bootstrap a Spykee robot +without the producers Windows and MacOSX software (I only have Linux, +so I had to ask a friend to come over to get the robot testing +going. :).</p> + +<p>Will release the source to the public soon, but need to figure out +where to make it available first. I will add a link to +<a href="http://wiki.nuug.no/grupper/robot/">the NUUG wiki</a> for +those that want to check back later to find it.</p> + + + Forslag i stortinget om å stoppe elektronisk stemmegiving i Norge http://people.skolelinux.org/pere/blog/Forslag_i_stortinget_om____stoppe_elektronisk_stemmegiving_i_Norge.html @@ -369,130 +426,5 @@ long time.</p> - - No hardcoded config on Debian Edu clients - http://people.skolelinux.org/pere/blog/No_hardcoded_config_on_Debian_Edu_clients.html - http://people.skolelinux.org/pere/blog/No_hardcoded_config_on_Debian_Edu_clients.html - Mon, 9 Aug 2010 20:15:00 +0200 - -<p>As reported earlier, the last few days I have looked at how Debian -Edu clients are configured, and tried to get rid of all hardcoded -configuration settings on the clients. I believe the work to be -mostly done, and the clients seem to work just fine with dynamically -generated configuration.</p> - -<p>What is the point, you might ask? The point is to allow a Debian -Edu desktop to integrate into an existing network infrastructure -without any manual configuration.</p> - -<p>This is what happens when installing a Debian Edu client here at -the University of Oslo using PXE. With the PXE installation, I am -asked for language (Norwegian Bokmål), locality (Norway) and keyboard -layout (no-latin1), Debian Edu profile (Roaming Workstation), if I -accept to reformat the hard drive (yes), if I want to submit info to -popcon.debian.org (no) and root password (secret). After answering -these questions, the installer goes ahead and does its thing, and -after around 50 minutes it is done. I press enter to finish the -installation, and the machine reboots into KDE. When the machine is -ready and kdm asks for login information, I enter my university -username and password, am told by kdm that a local home directory has -been created and that I must log in again, and finally log in with the -same username and password to the KDE 4.4 desktop. At no point during -this process did it ask for university specific settings, and all the -required configuration was dynamically detected using information -fetched via DHCP and DNS. The roaming workstation is now ready for -use.</p> - -<p>How was this done, you might wonder? First of all, here is the -list of things that need to be configured on the client to get it -working properly out of the box:</p> - -<ul> -<li>IP address/netmask and DNS server.</li> -<li>Web proxy URL.</li> -<li>LDAP server for NSS directory information (user, group, etc).</li> -<li>Kerberos server for PAM password checking.</li> -<li>SMB mount point to access the network home directory. (*)</li> -<li>Central syslog server to send syslog messages to. (*)</li> -<li>Sitesummary collector URL to submit info to central server. (*)</li> -</ul> - -<p>(Hm, did I forget anything? Let me knew if I did.)</p> - -<p>The points marked (*) are not required to be able to use the -machine, but needed to provide central storage and allowing system -administrators to track their machines. Since yesterday, everything -but the sitesummary collector URL is dynamically discovered at boot -and installation time in the svn version of Debian Edu.</p> - -<p>The IP and DNS setup is fetched during boot using DHCP as usual. -When a DHCP update arrives, the proxy setup is updated by looking for -http://wpat/wpad.dat and using the content of this WPAD file to -configure the http and ftp proxy in /etc/environment and -/etc/apt/apt.conf. I decided to update the proxy setup using a DHCP -hook to ensure that the client stops using the Debian Edu proxy when -it is moved outside the Debian Edu network, and instead uses any local -proxy present on the new network when it moves around.</p> - -<p>The DNS names of the LDAP, Kerberos and syslog server and related -configuration are generated using DNS information at boot. First the -installer looks for a host named ldap in the current DNS domain. If -not found, it looks for _ldap._tcp SRV records in DNS instead. If an -LDAP server is found, its root DSE entry is requested and the -attributes namingContexts and defaultNamingContext are used to -determine which LDAP base to use for NSS. If there are several -namingContexts attibutes and the defaultNamingContext is present, that -LDAP subtree is used as the base. If defaultNamingContext is missing, -the subtrees listed as namingContexts are searched in sequence for any -object with class posixAccount or posixGroup, and the first one with -such an object is used as the LDAP base. For Kerberos, a similar -search is done by first looking for a host named kerberos, and then -for the _kerberos._tcp SRV record. I've been unable to find a way to -look up the Kerberos realm, so for this the upper case string of the -current DNS domain is used.</p> - -<p>For the syslog server, the hosts syslog and loghost are searched -for, and the _syslog._udp SRV record is consulted if no such host is -found. This algorithm works for both Debian Edu and the University of -Oslo. A similar strategy would work for locating the sitesummary -server, but have not been implemented yet. I decided to fetch and -save these settings during installation, to make sure moving to a -different network does not change the set of users being allowed to -log in nor the passwords required to log in. Usernames and passwords -will be cached by sssd when the user logs in on the Debian Edu -network, and will not change as the laptop move around. For a -non-roaming machine, there is no caching, but given that it is -supposed to stay in place it should not matter much. Perhaps we -should switch those to use sssd too?</p> - -<p>The user's SMB mount point for the network home directory is -located when the user logs in for the first time. The LDAP server is -consulted to look for the user's LDAP object and the sambaHomePath -attribute is used if found. If it isn't found, the home directory -path fetched from NSS is used instead. Assuming the path is of the -form /site/server/directory/username, the second part is looked up in -DNS and used to generate a SMB URL of the form -smb://server.domain/username. This algorithm works for both Debian -edu and the University of Oslo. Perhaps there are better attributes -to use or a better algorithm that works for more sites, but this will -do for now. :)</p> - -<p>This work should make it easier to integrate the Debian Edu clients -into any LDAP/Kerberos infrastructure, and make the current setup even -more flexible than before. I suspect it will also work for thin -client servers, allowing one to easily set up LTSP and hook it into a -existing network infrastructure, but I have not had time to test this -yet.</p> - -<p>If you want to help out with implementing these things for Debian -Edu, please contact us on debian-edu@lists.debian.org.</p> - -<p>Update 2010-08-09: Simon Farnsworth gave me a heads-up on how to -detect Kerberos realm from DNS, by looking for _kerberos TXT entries -before falling back to the upper case DNS domain name. Will have to -implement it for Debian Edu. :)</p> - - -