<link>http://people.skolelinux.org/pere/blog/</link>
<atom:link href="http://people.skolelinux.org/pere/blog/index.rss" rel="self" type="application/rss+xml" />
+ <item>
+ <title>Testing sysvinit from experimental in Debian Hurd</title>
+ <link>http://people.skolelinux.org/pere/blog/Testing_sysvinit_from_experimental_in_Debian_Hurd.html</link>
+ <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Testing_sysvinit_from_experimental_in_Debian_Hurd.html</guid>
+ <pubDate>Mon, 3 Feb 2014 13:40:00 +0100</pubDate>
+ <description><p>A few days ago I decided to try to help the Hurd people to get
+their changes into sysvinit, to allow them to use the normal sysvinit
+boot system instead of their old one. This follow up on the
+<a href="https://teythoon.cryptobitch.de//categories/gsoc.html">great
+Google Summer of Code work</a> done last summer by Justus Winter to
+get Debian on Hurd working more like Debian on Linux. To get started,
+I downloaded a prebuilt hard disk image from
+<a href="http://ftp.debian-ports.org/debian-cd/hurd-i386/current/debian-hurd.img.tar.gz">http://ftp.debian-ports.org/debian-cd/hurd-i386/current/debian-hurd.img.tar.gz</a>,
+and started it using virt-manager.</p>
+
+<p>The first think I had to do after logging in (root without any
+password) was to get the network operational. I followed
+<a href="https://www.debian.org/ports/hurd/hurd-install">the
+instructions on the Debian GNU/Hurd ports page</a> and ran these
+commands as root to get the machine to accept a IP address from the
+kvm internal DHCP server:</p>
+
+<p><blockquote><pre>
+settrans -fgap /dev/netdde /hurd/netdde
+pkill pfinet
+pkill devnode
+dhclient -v /dev/eth0
+</pre></blockquote></p>
+
+<p>After this, the machine had internet connectivity, and I could
+upgrade it and install the sysvinit packages from experimental and
+enable it as the default boot system in Hurd.</p>
+
+<p>But before I did that, I set a password on the root user, as ssh is
+running on the machine it for ssh login to work a password need to be
+set. Also, note that a bug somewhere in openssh on Hurd block
+compression from working. Remember to turn that off on the client
+side.</p>
+
+<p>Run these commands as root to upgrade and test the new sysvinit
+stuff:</p>
+
+<p><blockquote><pre>
+cat > /etc/apt/sources.list.d/experimental.list &lt;&lt;EOF
+deb http://http.debian.net/debian/ experimental main
+EOF
+apt-get update
+apt-get dist-upgrade
+apt-get install -t experimental initscripts sysv-rc sysvinit \
+ sysvinit-core sysvinit-utils
+update-alternatives --config runsystem
+</pre></blockquote></p>
+
+<p>To reboot after switching boot system, you have to use
+<tt>reboot-hurd</tt> instead of just <tt>reboot</tt>, as there is not
+yet a sysvinit process able to receive the signals from the normal
+'reboot' command. After switching to sysvinit as the boot system,
+upgrading every package and rebooting, the network come up with DHCP
+after boot as it should, and the settrans/pkill hack mentioned at the
+start is no longer needed. But for some strange reason, there are no
+longer any login prompt in the virtual console, so I logged in using
+ssh instead.
+
+<p>Note that there are some race conditions in Hurd making the boot
+fail some times. No idea what the cause is, but hope the Hurd porters
+figure it out. At least Justus said on IRC (#debian-hurd on
+irc.debian.org) that they are aware of the problem. A way to reduce
+the impact is to upgrade to the Hurd packages built by Justus by
+adding this repository to the machine:</p>
+
+<p><blockquote><pre>
+cat > /etc/apt/sources.list.d/hurd-ci.list &lt;&lt;EOF
+deb http://darnassus.sceen.net/~teythoon/hurd-ci/ sid main
+EOF
+</pre></blockquote></p>
+
+<p>At the moment the prebuilt virtual machine get some packages from
+http://ftp.debian-ports.org/debian, because some of the packages in
+unstable do not yet include the required patches that are lingering in
+BTS. This is the completely list of "unofficial" packages installed:</p>
+
+<p><blockquote><pre>
+# aptitude search '?narrow(?version(CURRENT),?origin(Debian Ports))'
+i emacs - GNU Emacs editor (metapackage)
+i gdb - GNU Debugger
+i hurd-recommended - Miscellaneous translators
+i isc-dhcp-client - ISC DHCP client
+i isc-dhcp-common - common files used by all the isc-dhcp* packages
+i libc-bin - Embedded GNU C Library: Binaries
+i libc-dev-bin - Embedded GNU C Library: Development binaries
+i libc0.3 - Embedded GNU C Library: Shared libraries
+i A libc0.3-dbg - Embedded GNU C Library: detached debugging symbols
+i libc0.3-dev - Embedded GNU C Library: Development Libraries and Hea
+i multiarch-support - Transitional package to ensure multiarch compatibilit
+i A x11-common - X Window System (X.Org) infrastructure
+i xorg - X.Org X Window System
+i A xserver-xorg - X.Org X server
+i A xserver-xorg-input-all - X.Org X server -- input driver metapackage
+#
+</pre></blockquote></p>
+
+<p>All in all, testing hurd has been an interesting experience. :)
+X.org did not work out of the box and I never took the time to follow
+the porters instructions to fix it. This time I was interested in the
+command line stuff.<p>
+</description>
+ </item>
+
+ <item>
+ <title>A fist full of non-anonymous Bitcoins</title>
+ <link>http://people.skolelinux.org/pere/blog/A_fist_full_of_non_anonymous_Bitcoins.html</link>
+ <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/A_fist_full_of_non_anonymous_Bitcoins.html</guid>
+ <pubDate>Wed, 29 Jan 2014 14:10:00 +0100</pubDate>
+ <description><p>Bitcoin is a incredible use of peer to peer communication and
+encryption, allowing direct and immediate money transfer without any
+central control. It is sometimes claimed to be ideal for illegal
+activity, which I believe is quite a long way from the truth. At least
+I would not conduct illegal money transfers using a system where the
+details of every transaction are kept forever. This point is
+investigated in
+<a href="https://www.usenix.org/publications/login">USENIX ;login:</a>
+from December 2013, in the article
+"<a href="https://www.usenix.org/system/files/login/articles/03_meiklejohn-online.pdf">A
+Fistful of Bitcoins - Characterizing Payments Among Men with No
+Names</a>" by Sarah Meiklejohn, Marjori Pomarole,Grant Jordan, Kirill
+Levchenko, Damon McCoy, Geoffrey M. Voelker, and Stefan Savage. They
+analyse the transaction log in the Bitcoin system, using it to find
+addresses belong to individuals and organisations and follow the flow
+of money from both Bitcoin theft and trades on Silk Road to where the
+money end up. This is how they wrap up their article:</p>
+
+<p><blockquote>
+<p>"To demonstrate the usefulness of this type of analysis, we turned
+our attention to criminal activity. In the Bitcoin economy, criminal
+activity can appear in a number of forms, such as dealing drugs on
+Silk Road or simply stealing someone else’s bitcoins. We followed the
+flow of bitcoins out of Silk Road (in particular, from one notorious
+address) and from a number of highly publicized thefts to see whether
+we could track the bitcoins to known services. Although some of the
+thieves attempted to use sophisticated mixing techniques (or possibly
+mix services) to obscure the flow of bitcoins, for the most part
+tracking the bitcoins was quite straightforward, and we ultimately saw
+large quantities of bitcoins flow to a variety of exchanges directly
+from the point of theft (or the withdrawal from Silk Road).</p>
+
+<p>As acknowledged above, following stolen bitcoins to the point at
+which they are deposited into an exchange does not in itself identify
+the thief; however, it does enable further de-anonymization in the
+case in which certain agencies can determine (through, for example,
+subpoena power) the real-world owner of the account into which the
+stolen bitcoins were deposited. Because such exchanges seem to serve
+as chokepoints into and out of the Bitcoin economy (i.e., there are
+few alternative ways to cash out), we conclude that using Bitcoin for
+money laundering or other illicit purposes does not (at least at
+present) seem to be particularly attractive."</p>
+</blockquote><p>
+
+<p>These researches are not the first to analyse the Bitcoin
+transaction log. The 2011 paper
+"<a href="http://arxiv.org/abs/1107.4524">An Analysis of Anonymity in
+the Bitcoin System</A>" by Fergal Reid and Martin Harrigan is
+summarized like this:</p>
+
+<p><blockquote>
+"Anonymity in Bitcoin, a peer-to-peer electronic currency system, is a
+complicated issue. Within the system, users are identified by
+public-keys only. An attacker wishing to de-anonymize its users will
+attempt to construct the one-to-many mapping between users and
+public-keys and associate information external to the system with the
+users. Bitcoin tries to prevent this attack by storing the mapping of
+a user to his or her public-keys on that user's node only and by
+allowing each user to generate as many public-keys as required. In
+this chapter we consider the topological structure of two networks
+derived from Bitcoin's public transaction history. We show that the
+two networks have a non-trivial topological structure, provide
+complementary views of the Bitcoin system and have implications for
+anonymity. We combine these structures with external information and
+techniques such as context discovery and flow analysis to investigate
+an alleged theft of Bitcoins, which, at the time of the theft, had a
+market value of approximately half a million U.S. dollars."
+</blockquote></p>
+
+<p>I hope these references can help kill the urban myth that Bitcoin
+is anonymous. It isn't really a good fit for illegal activites. Use
+cash if you need to stay anonymous, at least until regular DNA
+sampling of notes and coins become the norm. :)</p>
+
+<p>As usual, if you use Bitcoin and want to show your support of my
+activities, please send Bitcoin donations to my address
+<b><a href="bitcoin:15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b&label=PetterReinholdtsenBlog">15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b</a></b>.</p>
+</description>
+ </item>
+
+ <item>
+ <title>New chrpath release 0.16</title>
+ <link>http://people.skolelinux.org/pere/blog/New_chrpath_release_0_16.html</link>
+ <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/New_chrpath_release_0_16.html</guid>
+ <pubDate>Tue, 14 Jan 2014 11:00:00 +0100</pubDate>
+ <description><p><a href="http://www.coverity.com/">Coverity</a> is a nice tool to
+find problems in C, C++ and Java code using static source code
+analysis. It can detect a lot of different problems, and is very
+useful to find memory and locking bugs in the error handling part of
+the source. The company behind it provide
+<a href="https://scan.coverity.com/">check of free software projects as
+a community service</a>, and many hundred free software projects are
+already checked. A few days ago I decided to have a closer look at
+the Coverity system, and discovered that the
+<a href="http://www.gnu.org/software/gnash/">gnash</a> and
+<a href="http://sourceforge.net/projects/ipmitool/">ipmitool</a>
+projects I am involved with was already registered. But these are
+fairly big, and I would also like to have a small and easy project to
+check, and decided to <a href="http://scan.coverity.com/projects/1179">request
+checking of the chrpath project</a>. It was
+added to the checker and discovered seven potential defects. Six of
+these were real, mostly resource "leak" when the program detected an
+error. Nothing serious, as the resources would be released a fraction
+of a second later when the program exited because of the error, but it
+is nice to do it right in case the source of the program some time in
+the future end up in a library. Having fixed all defects and added
+<a href="https://lists.alioth.debian.org/mailman/listinfo/chrpath-devel">a
+mailing list for the chrpath developers</a>, I decided it was time to
+publish a new release. These are the release notes:</p>
+
+<p>New in 0.16 released 2014-01-14:</p>
+
+<ul>
+
+ <li>Fixed all minor bugs discovered by Coverity.</li>
+ <li>Updated config.sub and config.guess from the GNU project.</li>
+ <li>Mention new project mailing list in the documentation.</li>
+
+</ul>
+
+<p>You can
+<a href="https://alioth.debian.org/frs/?group_id=31052">download the
+new version 0.16 from alioth</a>. Please let us know via the Alioth
+project if something is wrong with the new release. The test suite
+did not discover any old errors, so if you find a new one, please also
+include a test suite check.</p>
+</description>
+ </item>
+
<item>
<title>Debian Edu interview: Dominik George</title>
<link>http://people.skolelinux.org/pere/blog/Debian_Edu_interview__Dominik_George.html</link>
</description>
</item>
- <item>
- <title>All drones should be radio marked with what they do and who they belong to</title>
- <link>http://people.skolelinux.org/pere/blog/All_drones_should_be_radio_marked_with_what_they_do_and_who_they_belong_to.html</link>
- <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/All_drones_should_be_radio_marked_with_what_they_do_and_who_they_belong_to.html</guid>
- <pubDate>Thu, 21 Nov 2013 15:40:00 +0100</pubDate>
- <description><p>Drones, flying robots, are getting more and more popular. The most
-know ones are the killer drones used by some government to murder
-people they do not like without giving them the chance of a fair
-trial, but the technology have many good uses too, from mapping and
-forest maintenance to photography and search and rescue. I am sure it
-is just a question of time before "bad drones" are in the hands of
-private enterprises and not only state criminals but petty criminals
-too. The drone technology is very useful and very dangerous. To have
-some control over the use of drones, I agree with Daniel Suarez in his
-TED talk
-"<a href="https://archive.org/details/DanielSuarez_2013G">The kill
-decision shouldn't belong to a robot</a>", where he suggested this
-little gem to keep the good while limiting the bad use of drones:</p>
-
-<blockquote>
-
-<p>Each robot and drone should have a cryptographically signed
-I.D. burned in at the factory that can be used to track its movement
-through public spaces. We have license plates on cars, tail numbers on
-aircraft. This is no different. And every citizen should be able to
-download an app that shows the population of drones and autonomous
-vehicles moving through public spaces around them, both right now and
-historically. And civic leaders should deploy sensors and civic drones
-to detect rogue drones, and instead of sending killer drones of their
-own up to shoot them down, they should notify humans to their
-presence. And in certain very high-security areas, perhaps civic
-drones would snare them and drag them off to a bomb disposal facility.</p>
-
-<p>But notice, this is more an immune system than a weapons system. It
-would allow us to avail ourselves of the use of autonomous vehicles
-and drones while still preserving our open, civil society.</p>
-
-</blockquote>
-
-<p>The key is that <em>every citizen</em> should be able to read the
-radio beacons sent from the drones in the area, to be able to check
-both the government and others use of drones. For such control to be
-effective, everyone must be able to do it. What should such beacon
-contain? At least formal owner, purpose, contact information and GPS
-location. Probably also the origin and target position of the current
-flight. And perhaps some registration number to be able to look up
-the drone in a central database tracking their movement. Robots
-should not have privacy. It is people who need privacy.</p>
-</description>
- </item>
-
- <item>
- <title>Lets make a wireless community network in Oslo!</title>
- <link>http://people.skolelinux.org/pere/blog/Lets_make_a_wireless_community_network_in_Oslo_.html</link>
- <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Lets_make_a_wireless_community_network_in_Oslo_.html</guid>
- <pubDate>Wed, 13 Nov 2013 21:00:00 +0100</pubDate>
- <description><p>Today NUUG and Hackeriet announced
-<a href="http://www.nuug.no/news/Bli_med___bygge_dugnadsnett_for_alle_i_Oslo.shtml">our
-plans to join forces and create a wireless community network in
-Oslo</a>. The workshop to help people get started will take place
-Thursday 2013-11-28, but we already are collecting the geolocation of
-people joining forces to make this happen. We have
-<a href="https://github.com/petterreinholdtsen/meshfx-node/blob/master/oslo-nodes.geojson">9
-locations plotted on the map</a>, but we will need more before we have
-a connected mesh spread across Oslo. If this sound interesting to
-you, please join us at the workshop. If you are too impatient to wait
-15 days, please join us on the IRC channel
-<a href="irc://irc.freenode.net/%23nuug">#nuug on irc.freenode.net</a>
-right away. :)</p>
-</description>
- </item>
-
- <item>
- <title>Running TP-Link MR3040 as a batman-adv mesh node using openwrt</title>
- <link>http://people.skolelinux.org/pere/blog/Running_TP_Link_MR3040_as_a_batman_adv_mesh_node_using_openwrt.html</link>
- <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Running_TP_Link_MR3040_as_a_batman_adv_mesh_node_using_openwrt.html</guid>
- <pubDate>Sun, 10 Nov 2013 23:00:00 +0100</pubDate>
- <description><p>Continuing my research into mesh networking, I was recommended to
-use TP-Link 3040 and 3600 access points as mesh nodes, and the pair I
-bought arrived on Friday. Here are my notes on how to set up the
-MR3040 as a mesh node using
-<a href="http://www.openwrt.org/">OpenWrt</a>.</p>
-
-<p>I started by following the instructions on the OpenWRT wiki for
-<a href="http://wiki.openwrt.org/toh/tp-link/tl-mr3040">TL-MR3040</a>,
-and downloaded
-<a href="http://downloads.openwrt.org/snapshots/trunk/ar71xx/openwrt-ar71xx-generic-tl-mr3040-v2-squashfs-factory.bin">the
-recommended firmware image</a>
-(openwrt-ar71xx-generic-tl-mr3040-v2-squashfs-factory.bin) and
-uploaded it into the original web interface. The flashing went fine,
-and the machine was available via telnet on the ethernet port. After
-logging in and setting the root password, ssh was available and I
-could start to set it up as a batman-adv mesh node.</p>
-
-<p>I started off by reading the instructions from
-<a href="http://wirelessafrica.meraka.org.za/wiki/index.php?title=Antoine's_Research">Wireless
-Africa</a>, which had quite a lot of useful information, but
-eventually I followed the recipe from the Open Mesh wiki for
-<a href="http://www.open-mesh.org/projects/batman-adv/wiki/Batman-adv-openwrt-config">using
-batman-adv on OpenWrt</a>. A small snag was the fact that the
-<tt>opkg install kmod-batman-adv</tt> command did not work as it
-should. The batman-adv kernel module would fail to load because its
-dependency crc16 was not already loaded. I
-<a href="https://dev.openwrt.org/ticket/14452">reported the bug</a> to
-the openwrt project and hope it will be fixed soon. But the problem
-only seem to affect initial testing of batman-adv, as configuration
-seem to work when booting from scratch.</p>
-
-<p>The setup is done using files in /etc/config/. I did not bridge
-the Ethernet and mesh interfaces this time, to be able to hook up the
-box on my local network and log into it for configuration updates.
-The following files were changed and look like this after modifying
-them:</p>
-
-<p><tt>/etc/config/network</tt></p>
-
-<pre>
-
-config interface 'loopback'
- option ifname 'lo'
- option proto 'static'
- option ipaddr '127.0.0.1'
- option netmask '255.0.0.0'
-
-config globals 'globals'
- option ula_prefix 'fdbf:4c12:3fed::/48'
-
-config interface 'lan'
- option ifname 'eth0'
- option type 'bridge'
- option proto 'dhcp'
- option ipaddr '192.168.1.1'
- option netmask '255.255.255.0'
- option hostname 'tl-mr3040'
- option ip6assign '60'
-
-config interface 'mesh'
- option ifname 'adhoc0'
- option mtu '1528'
- option proto 'batadv'
- option mesh 'bat0'
-</pre>
-
-<p><tt>/etc/config/wireless</tt></p>
-<pre>
-
-config wifi-device 'radio0'
- option type 'mac80211'
- option channel '11'
- option hwmode '11ng'
- option path 'platform/ar933x_wmac'
- option htmode 'HT20'
- list ht_capab 'SHORT-GI-20'
- list ht_capab 'SHORT-GI-40'
- list ht_capab 'RX-STBC1'
- list ht_capab 'DSSS_CCK-40'
- option disabled '0'
-
-config wifi-iface 'wmesh'
- option device 'radio0'
- option ifname 'adhoc0'
- option network 'mesh'
- option encryption 'none'
- option mode 'adhoc'
- option bssid '02:BA:00:00:00:01'
- option ssid 'meshfx@hackeriet'
-</pre>
-<p><tt>/etc/config/batman-adv</tt></p>
-<pre>
-
-config 'mesh' 'bat0'
- option interfaces 'adhoc0'
- option 'aggregated_ogms'
- option 'ap_isolation'
- option 'bonding'
- option 'fragmentation'
- option 'gw_bandwidth'
- option 'gw_mode'
- option 'gw_sel_class'
- option 'log_level'
- option 'orig_interval'
- option 'vis_mode'
- option 'bridge_loop_avoidance'
- option 'distributed_arp_table'
- option 'network_coding'
- option 'hop_penalty'
-
-# yet another batX instance
-# config 'mesh' 'bat5'
-# option 'interfaces' 'second_mesh'
-</pre>
-
-<p>The mesh node is now operational. I have yet to test its range,
-but I hope it is good. I have not yet tested the TP-Link 3600 box
-still wrapped up in plastic.</p>
-</description>
- </item>
-
</channel>
</rss>
projects / homepage.git / blobdiff