pvaneynd: (Default)
Given some people having rainbow tables I'm now waisting a lot of cpu time doing:
for i in 2046 3072 4096 6144 7680 8192 ; do 
  ssh-keygen -G moduli-$i.candidates -b $i 
  ssh-keygen -T moduli-$i -f moduli-$i.candidates 
done
mv /etc/ssh/moduli /etc/ssh/moduli-normal
cat moduli-[23478]* > /etc/ssh/moduli
systemctl restart ssh.service
This should give me brand-new primes, used only by me. So even if 'bad people' spend a lot of time and money hacking the 20 odd 2048-bit primes distributed with ssh, I would be ... higher on their target list?
pvaneynd: (Default)
A had a long string of problems with our server at home... Read more... )
pvaneynd: (Default)
Today I helped a collegue who came with the question: I have two files, how do I find which lines were added to one file, but not to the other?

He was thinking of a program to write. I'm more a KISS person, why waste time writing a program when brute force will do just fine.

So:

We have two files a and b:

pevaneyn@mac-book:/tmp :) $ cat a
1
2
3
4
5
pevaneyn@mac-book:/tmp :) $ cat b
1
2
3
4
5
7
8


We want to see the lines in b which are not in a:

pevaneyn@mac-book:/tmp :) $ cat a b | sort | uniq -u
7
8


So we take the two files, sort then and then print the unique lines.

But what if there are also unique lines in a which we don't need? So let's add a line to 0 which we do not want to see in the output:

pevaneyn@mac-book:/tmp :) $ cat >> a
0
pevaneyn@Pmac-book:/tmp :) $ cat a b | sort | uniq -u
0
7
8


How do we remove this 0?

A trick is to include a twice, then a line in a will never be unique:

pevaneyn@mac-book:/tmp :) $ cat a a b | sort | uniq -u
7
8


I used a similar method today to find which interface gave the CRC errors...
pvaneynd: (Default)
This morning while waking up I was dreaming about the culture.

It started off as a pretty normal dream involving a hidden base where we lived, with an alien space ship inside of it. The main part was that it was well protected about the rain ;). (It rained a lot here yesterday)

Then it went a bit Casablanca on me because another space ship case to visit the base. The avatar of that ship talked with the alien ship and after a while complained that they were discussing in 'greed'. The alien ship replied that 'greed' was an exact language leaving no ambiguities, like Marain. The avatar replied that indeed 'greed' was almost as exact and well specified as Marain, but that the core of 'greed' is about what you wanted and it limites the possibilities. Marain on the other hand talked about what was possible and the infinite possibilities out there.

Then I realised I was dreaming a Culture novel, and irritatingly woke up.
pvaneynd: (Default)
Ever since I had the Mercedes E200 ipod touch/iphone integration I had problems with the player jumping to the start of any podcast it had started. It simply forgot the location.

Which is rather irritating if you are 45 minutes into a 1 hour podcast.

In the last few days I found a solution:

- unlock the ipod touch
- go to the music player, select the podcast
- go back 30 seconds (to not lose a few seconds)
- click 'play'
- attach the ipod touch to the car

there will be a few seconds of silence and then it will continue to play via the car at the right position.

Joy!
pvaneynd: (Default)


how so?

pevaneyn-mac:wireshark pevaneyn$ traceroute v4.fr.ipv6-test.com
traceroute to v4.fr.ipv6-test.com (46.105.61.149), 64 hops max, 52 byte packets
 1  193.191.79.254 (193.191.79.254)  6.215 ms  0.282 ms  0.244 ms
 2  ge.ar1.brucam.belnet.net (193.191.4.49)  0.350 ms  0.325 ms  0.365 ms
 3  10ge.cr2.bruvil.belnet.net (193.191.16.189)  1.143 ms  0.964 ms  0.994 ms
 4  ovh.bnix.net (194.53.172.70)  2.396 ms  1.900 ms  1.942 ms
 5  rbx-g2-a9.fr.eu (94.23.122.137)  5.712 ms  4.725 ms  4.794 ms
 6  rbx-2-6k.fr.eu (91.121.131.9)  10.489 ms  15.149 ms
    rbx-1-6k.fr.eu (91.121.131.13)  50.591 ms
 7  rbx-26-m1.fr.eu (213.251.191.201)  4.448 ms
    rbx-26-m1.routers.ovh.net (213.251.191.73)  4.754 ms  4.996 ms
 8  eight.t0x.net (46.105.61.149)  3.950 ms  3.975 ms  4.067 ms
pevaneyn-mac:wireshark pevaneyn$ traceroute6 v6.fr.ipv6-test.com
traceroute6 to v6.fr.ipv6-test.com (2001:41d0:1:d87c::7e57:1) from 2001:6a8:1100:beef:114f:fb76:XXXX:XXXX, 64 hops max, 12 byte packets
 1  2001:6a8:1100:beef::1  0.558 ms  0.674 ms  0.507 ms
 2  2001:6a8:1000:800f::1  0.370 ms  0.414 ms  0.393 ms
 3  10ge.cr2.bruvil.belnet.net  1.106 ms  1.112 ms  1.034 ms
 4  ae0-200.bru20.ip6.tinet.net  1.620 ms  1.572 ms  1.523 ms
 5  xe-2-1-0.ams20.ip6.tinet.net  6.063 ms
    xe-5-2-0.ams20.ip6.tinet.net  5.999 ms
    xe-8-1-0.ams20.ip6.tinet.net  6.002 ms
 6  * * *
 7  * * *
 8  * * *
 9  fra-5-6k.de.eu  25.602 ms *  30.531 ms
10  rbx-g2-a9.fr.eu  31.890 ms  27.448 ms  26.656 ms
11  rbx-1-6k.fr.eu  29.996 ms
    rbx-2-6k.fr.eu  33.715 ms
    rbx-1-6k.fr.eu  26.735 ms
12  2001:41d0:1:d87c::7e57:1  25.498 ms  31.873 ms  30.815 ms


So a trip around Europe. But IPv6 needs not be slow:

pevaneyn-mac:fosdem pevaneyn$ traceroute6 www.debian.org
traceroute6: Warning: www.debian.org has multiple addresses; using 2001:858:2:2:214:22ff:fe0d:7717
traceroute6 to www.debian.org (2001:858:2:2:214:22ff:fe0d:7717) from 2001:6a8:1100:beef:114f:fb76:XXXX:XXXX, 64 hops max, 12 byte packets
 1  2001:6a8:1100:beef::1  0.640 ms  1.731 ms  0.607 ms
 2  2001:6a8:1000:800f::1  0.491 ms  0.356 ms  0.387 ms
 3  2001:6a8:1000:2::2  0.442 ms
    10ge.cr2.bruvil.belnet.net  1.081 ms  0.989 ms
 4  10ge.cr1.brueve.belnet.net  1.979 ms
    10ge.cr1.brueve.belnet.net  1.718 ms  1.479 ms
 5  20gigabitethernet1-3.core1.ams1.ipv6.he.net  4.766 ms  8.460 ms  7.190 ms
 6  10gigabitethernet1-1.core1.fra1.he.net  16.977 ms  20.783 ms  11.835 ms
 7  ge2-19-decix-ipv6-c1.ix.sil.at  70.823 ms  42.928 ms  45.012 ms
 8  2001:858:66:203:215:2cff:fe8d:bc00  27.416 ms  26.934 ms  28.561 ms
 9  ip6-te1-4-c2.oe3.sil.at  26.776 ms  26.413 ms  26.856 ms
10  2001:858:66:22c:217:fff:fed4:6000  27.156 ms  27.472 ms  26.778 ms
11  englund.debian.org  27.211 ms  27.641 ms  27.823 ms
pevaneyn-mac:fosdem pevaneyn$ traceroute www.debian.org
traceroute: Warning: www.debian.org has multiple addresses; using 86.59.118.148
traceroute to www.debian.org (86.59.118.148), 64 hops max, 52 byte packets
 1  193.191.79.254 (193.191.79.254)  0.619 ms  0.254 ms  0.255 ms
 2  ge.ar1.brucam.belnet.net (193.191.4.49)  0.432 ms  0.385 ms  0.448 ms
 3  10ge.cr1.brueve.belnet.net (193.191.16.205)  1.153 ms  1.557 ms  0.951 ms
 4  nl-asd-dc2-ias-csg01.nl.kpn.net (195.69.144.144)  5.608 ms  5.442 ms  10.251 ms
 5  * * *
 6  ffm-s1-rou-1021.de.eurorings.net (134.222.229.10)  38.019 ms  37.926 ms
    ffm-s1-rou-1021.de.eurorings.net (134.222.231.250)  39.953 ms
 7  ffm-s1-rou-1022.de.eurorings.net (134.222.228.86)  40.075 ms
    ffm-s1-rou-1022.de.eurorings.net (134.222.228.90)  38.180 ms
    ffm-s1-rou-1022.de.eurorings.net (134.222.228.86)  42.755 ms
 8  mchn-s1-rou-1022.de.eurorings.net (134.222.228.194)  33.019 ms  33.211 ms  37.045 ms
 9  wien-s2-rou-1002.at.eurorings.net (134.222.228.46)  39.827 ms  37.795 ms  39.839 ms
10  wien-s2-rou-1041.at.eurorings.net (134.222.123.242)  37.581 ms  37.633 ms  39.505 ms
11  sil.cust.at.eurorings.net (134.222.123.150)  37.654 ms  35.650 ms  35.521 ms
12  englund.debian.org (86.59.118.148)  38.009 ms  38.124 ms  40.628 ms
pvaneynd: (Default)
For some reason my involvement with Fosdem is going up, not down.

So I will certainly be there, find me hacking the network again. Learning QoS in a trial by fire :).
pvaneynd: (Default)
This morning I thought let's update our dreambox 500hd satellite receiver to run the new OpenPLI 2.1 version.

Normally it's an opkg update && opkg upgrade away, but the 2.1 release requires that you flash the new firmware. It's not so bad as they have auto-install which can restore all your settings and added plugins automagically.

Anyway the procedure is normally pretty simple: shutdown the device using the power switch at the back, turn it back on while pressing the power button at the front. It goes into the 'BIOS', shows the IP address it gets from DHCP on the screen. You go there with a browser and install the new flash.

Except this time.

It would keep hanging on me and showing a green screen. It would even do this if I just looked at it without doing anything. (I checked using tcpdump)

So... what changed? This worked previously... IPv6? No the BIOS is too stupid. The new Argus monitoring which I setup recently? Could be...

Then it hit me: previously the BIOS would get some random IP, but I had changed the DHCP server to give the 'correct' IP to the device (normally it uses a hardcoded IP). And of course in the past all my monitoring scripts and other stuff would not be able to connect, as the IP was different.

But now it was 'correct' so they would try to log in and check for things... in the BIOS setup screen...

I removed the DHCP permanent binding, it got a random IP and stopped crashing with a green screen :). Mystery solved, system upgrade.
pvaneynd: (Default)
I've installed Debian sid in a FreeBSD 8.2 jail and I'm seeing this weird effect:
root@debian:~# aptitude upgrade
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
                                         
User defined signal 1
root@debian:~#

This will randomly kill the normal aptitude gui, while other things like vim or dpkg-reconfigure using the 'dialog' gui will work normally.

Google is useless. strace doesn't work. ktrace gives
21131 100410 aptitude-curses CALL stat(0x9ef968,0x7fffffffe810)
21131 100410 aptitude-curses NAMI "/tmp/aptitude-root.21131:mvkyG0"
21131 100410 aptitude-curses STRU invalid record
21131 100410 aptitude-curses RET stat 0
21131 100410 aptitude-curses CALL open(0x9ef968,O_NONBLOCK,0)
21131 100410 aptitude-curses NAMI "/tmp/aptitude-root.21131:mvkyG0"
21131 100410 aptitude-curses RET open 3
21131 100410 aptitude-curses CALL fstat(0x3,0x7fffffffe810)
21131 100410 aptitude-curses STRU invalid record
21131 100410 aptitude-curses RET fstat 0
21131 100410 aptitude-curses CALL fcntl(0x3,<invalid=2>,FD_CLOEXEC)
21131 100410 aptitude-curses RET fcntl 0
21131 100410 aptitude-curses CALL getdents(0x3,0x1b9e630,0x20000)
21131 100410 aptitude-curses RET getdents 24/0x18
21131 100410 aptitude-curses CALL getdents(0x3,0x1b9e630,0x20000)
21131 100410 aptitude-curses RET getdents 0
21131 100410 aptitude-curses CALL close(0x3)
21131 100410 aptitude-curses RET close 0
21131 100410 aptitude-curses CALL rmdir(0x9ef968)
21131 100410 aptitude-curses NAMI "/tmp/aptitude-root.21131:mvkyG0"
21131 100410 aptitude-curses RET rmdir 0
21131 100410 aptitude-curses CALL write(0x28,0x7fffffffeb20,0x38)
21131 100410 aptitude-curses GIO fd 40 wrote 56 bytes
0x0000 4026 a000 0800 0000 0200 0000 0800 0000 0000 0000 0800 0000 0000 0000 0000 0000 2818 0803 0800 0000 a0f9 9d00 0000 0000 0100 0000 |@&..............................(...................|
0x0034 0000 0000 |....|

21131 100410 aptitude-curses RET write 56/0x38
21131 100410 aptitude-curses CALL sigprocmask(SIG_SETMASK,0,0x7fffffffeaf0)
21131 100410 aptitude-curses RET sigprocmask 0
21131 100410 aptitude-curses PSIG SIGUSR1 SIG_DFL



Anybody has an idea?

root@debian:~# uname -a
GNU/kFreeBSD debian.home 8.2-RELEASE FreeBSD 8.2-RELEASE #1: Wed Apr 6 09:52:09 CEST 2011 root@frost.local:/usr/obj/usr/src/sys/PEVANEYN x86_64 amd64 Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz GNU/kFreeBSD
pvaneynd: (Default)
Now that my server at home is running FreeBSD on top of ZFS for a while now I though to setup the backups again.

Now I have 3 disks in the server, 2 are reliable and are used in the main ZFS pool (zroot), one is a POC WD 'green' disk that will die if you use it too often. So that one is my local backup disk.

My backup strategy is that I configured daily snapshots on zroot, I have the local backup disk and I'm using a USB hard disk for off-site backups.

At first I thought to use UFS2 on the third disks with rsync, like I did with Linux. Then I read a bit more about the ZFS functions and decided to use ZFS on the third disk. I created a 'fastbackup' pool and then used zfs send and zfs receive to sync the two pools. Syncing the disks was fast. Very fast indeed, about as fast as a simple 'dd' would have been.

However ZFS's magic does not end here. It has the option of sending incremental changes that happened between snapshots. So I wrote a script that makes a new snapshot ("nu" now in Dutch), sends the incremental changes to 'fastbackup' and then moved the reference snapshot forward. This to me seemed to be faster then using rsync. which would always take at least 5 minutes to declare that the filesystems were in sync. ZFS is ... faster:

+ zfs snapshot zroot/usr@nu
+ zfs send -vi zroot/usr@laatste zroot/usr@nu
+ zfs receive -Fv fastbackup/usr@nu
receiving incremental stream of zroot/usr@nu into fastbackup/usr@nu
received 597MB stream in 10 seconds (59.7MB/sec)


So that's a day worth of changes, including building and installing emacs and clisp, in 10 seconds.

Script I used below the cut.fastbackup.sh )
pvaneynd: (Default)
After a bit of work:

[root@frost ~]# uname -a
FreeBSD frost.local 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu Feb 17 02:41:51 UTC 2011 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64
[root@frost ~]# zpool status
pool: zroot
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
zroot ONLINE 0 0 0
mirror ONLINE 0 0 0
gpt/disk1 ONLINE 0 0 0
gpt/disk2 ONLINE 0 0 0

errors: No known data errors

[root@frost ~]# df -h /
Filesystem Size Used Avail Capacity Mounted on
zroot 1.4T 329M 1.4T 0% /


Turns out that converting from Debian to FreeBSD isn't that easy: in practice they share no advanced filesystem anymore, so I had to resort to:

tar cf /dev/sdc1 /home/ /root/ /etc/ /Media/ /Backups/

which is not very elegant. Now learning about the wonders of pkg_add and freebsd-update.

First thing: how to compile a kernel only for my hardware...
pvaneynd: (Default)
- a fuse can break
- it is most likely to do so just when people come to see if they want to buy your house
- a lamp has almost 0 resistance so you can check the wiring from the fuse box
- FreeBSD does not know lvm or dm so it is not so easy to copy information across
- fuse-zfs is not good enough to mount the FreeBSD zfs partitions
- the intel BIOS on my PC will not boot from a disk when no partition is marked as active
- installing FreeBSD mbr on a 2T disk fails, using ZFS on GPT works.


Open questions:
- I can install packages with "pkg_add -r <foo>", but how can I check for updates and update them?
pvaneynd: (Default)
I'm experimenting with zfs at home, for the moment on top of my md/lvm setup, and I ran out of disk space. Growing the lv is pretty easy:

frost:~# lvextend --size +110G /dev/new-vg/zfs-test
  Extending logical volume zfs-test to 120.00 GiB
  Logical volume zfs-test successfully resized
frost:~# zpool list
NAME       SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
zfs-pool  9.94G  9.78G   161M    98%  1.00x  ONLINE  -


Hmm it did not notice the 110GB extra, so I did:

frost:~# zpool export zfs-pool
frost:~# zpool import zfs-pool
frost:~# zpool list
NAME       SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
zfs-pool   120G  9.78G   110G     8%  1.00x  ONLINE  -


so simply doing an import/export is enough.

I'm looking at zfs to have a better idea of what btrfs will mean in the future for us.
pvaneynd: (Default)
If you are using something like git.debian.org to share repositories and you have done major surgery that makes that 'master' became invalid this is easy to fix in your local repository:

git checkout new-master
git branch -D master
git branch -m new-master master

but what do you do with the bare repository on git.debian.org? Well you can do:

git branch -m master old-master
git branch -m new-master master
git symbolic-ref HEAD refs/heads/master
git branch -D old-master

of course anybody who was following this git repository now has problems ...
pvaneynd: (Default)
ipv6 on ipod touch

That's at home with a SixXS tunnel... nice.
pvaneynd: (Default)
It combines the 'safety first' attitude of the Americans with the efficiency and organizational talents of the French.

To give you an idea: having a lunch appointment at 14:30 means: "you can come and queue at 14:30. People arriving after you, but who fit the table that just became free (ie. was empty for an hour and we finally got round to cleaning up) better will pass you by". Then they did not know about the non-allergic lunch options.

Tips:

  • Don't go: other parks have more attractions and less long queues. We especially liked Legoland

  • If you still decide to go:

    • don't buy the tickets online, you can buy 'yearly' tickets for the same price locally, and anyhow: you still need to queue at the ticket office even if you have bought online.

    • stay at the International Camping at Jablines. The people are nice, it is in a quiet beautiful setting and not far at all from the park.

    • bring your own food. All the French people are picnicking in the park...

    • decide what you want to do, rush to the attraction and get 'fast-path' tickets. Then queue at the next item on your list.

    • If you do want to get the allergic menu: go to the fast-food restaurant that serves them. They are in the computer and the people will just be slightly confused as to where to find them. You can heat them with the microwave in the restaurant itself.


It's not that we did not enjoy the trip, but we liked other parks better...

The main good thing is that we found out that the meals-for-allergic people are from an French company: Natâma. The meals are 'delicious' according to our tester and keep for more then a year. Not only that we also found a shop selling this locally: Allergoshop.

It is difficult to describe how wonderful it is to have found these meals. The company clearly understands the problems of allergic people and the information they give is so clear and nice to read compared to other 'ingredients lists' that we had to check twice. For example they tell you that the 'lactic acid' in the list is from bacteria, not from milk (as it can be). Then they have a pretty long "never-used" list of ingredients.

When our tester then announced that he really liked it ("I can eat that again tomorrow? ... YES OH YES!!") we went and got a few meals. So now we have a solution for all those school-excursions in the next few years :-).
pvaneynd: (Default)
From my lovely wife: (in Italian) "No, not xkcd first thing in the morning!"
pvaneynd: (Default)
My home server started acting up a while ago, yesterday I found that it was 'on' but non-reactive.

I removed it from the niche where it stands and I noticed it was really dusty. So I cleaned up all the dust that accumulated and it power on again without problems.

I started an 'aptitude update' cycle and when I came back a bit later it was unresponsive again. I tried resetting it, then did a hard power down. That at least worked. Then I turned it back on and I heard 'bzzzzz' followed by 'pop!' and the traditional 'burned electronics' smell.

Bummer. The power-supply let out all its magic smoke. Now I need to find a new one and I'm an OSX-only person until this is fixed.
pvaneynd: (Default)
1 GB uplink restored (5 out of 6 fibers had failed)
speed to Europe is good, speed to USA is not so good
got 500 Mbps on a download test on my Mac
tomorrow back early to get it working properly

CLC v7

Feb. 1st, 2010 09:24 pm
pvaneynd: (Default)
With a lot of help from Faré and James Y Knight we have now the incredible disappearing common-lisp-controller v7. We went from 617 to 267 lines which in fact are only 193 lines excluding comments and empty lines...

Using the new features of cl-asdf version 1.500 and higher the implementation of CLC is now merely setting a few variables and putting a few files into place. As an added bonus I added clbuild integration, so now people can download and update libraries with ease.

Still todo:
  • there is an bug (#567912) that the first call to (clc:clc-require :<foo>) will fail with clisp due to a loop where there is no looping...
  • We still need to find a way to precompile libraries
  • Because asdf is now taking care of placing the fasl file in the correct place, we cannot remove fasls for a specific implementation or library, so we nuke them all. Not optimal.
.

Still a nice improvement, I hope to find some time at fosdem to work on the other issues...

Profile

pvaneynd: (Default)
pvaneynd

March 2017

S M T W T F S
   1234
567891011
12131415 161718
19202122232425
26272829 3031 

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Apr. 24th, 2017 11:25 am
Powered by Dreamwidth Studios