Older blog entries for mones (starting at number 73)

Total time: 5 minutes 48 seconds

This is how long takes a deploy at localhost... when your work's laptop is a underpowered five year's old technology. That's probably not even true, as the time of marketing is usually way in the future from the time the technology does exist and is usable.

Obviously it's not all hardware's fault, the enterprise mandated heap of crap^W^W^Wstandard operating environment which runs on top of it does it's job by eating around a third of the 2 GB of total memory. Put a local Oracle and a couple of JVMs (eclipse and the application server) and you'll soon be swapping to disk.

I'm pretty tired of all this currently. I my last week vacation was canceled because of the project I had been unassigned from (and now reassigned again), and I really needed it. At least September will be better.

Syndicated 2010-08-04 08:36:57 from Ricardo Mones

Clawsker 0.7.1

Finally, only three months lather than announced, it has seen the light :-).

Unfortunately I've received no new translations, so it's even a more poor release than expected. Anyway, long life to release early, release often!

Syndicated 2010-05-14 17:06:45 from Ricardo Mones

running out of ids

Yep, our current client is pretty sure they're gonna run out of identifiers on the database tables (they're NUMBER(32,0) columns). Now we have to change the database design to have tables with composed primary keys, which will unnecesarily make the queries more complicated, instead our simple autonumeric key.

So what do they process? Not much in fact, around 500 requests per day. Oohh! Let's say 1000, to make you happy. Let's say also detail tables will grow even faster: 1000 lines per request (it's unrealistic, but WTF)... so you have now a million of ids used per day.

Well, sounds a lot... but don't be shy: suppose you have enough cores to process it, the bandwidth of several telcos and exabytes of database to waste, the crisis is over and you're the only vendor in the galaxy, so let's say you use 100 billion of ids per day (or 10^11).

That's really a lot! isn't it? Our little NUMBER(32,0) can hold up to 10^32 values, so at that
surrealistic rate you would exhaust it in 10^32 / 10^11 = 10^21 days, or divided by 365 and rounding 2.74 x 10^18 years, or, dividing again, approximately 210,000,000 times the estimated age of the known universe.

Yes, we're running out of ids... and surrounded by monkeys.

Syndicated 2010-05-04 14:34:22 from Ricardo Mones

dudesconf is over

Well, all good things come to an end, like the song says, so it does DudesConf. We had a very good time here, all the people was having fun and enjoying Debian and the great hospitality of the GPUL people, which make us feel like at home, like the previous times. Superb organization, I hope we can repeat the experience the next year.

I've also been able to put myself online again, so expect me fighting again ;-)

Syndicated 2010-04-11 13:58:15 from Ricardo Mones

dudesconf

Long time has passed since last post here. Real life in general and my paid job in particular has kept me too busy to leave room for anything else. Now seems things will be better: new project and new bosses (I'm in Ariba team again), though company is the same, so lets see how much it lasts.

Regarding free software there's not much to say, my online life never was so low and I've even lost some sponsored packages in Debian because my lack of activity. There's several hundreds of unread mails pending and things to be done are still to be done. Nevertheless, I'm now at DudesConf enjoying a nice sunny weekend at A Coruña, the talks of my Debian fellows and trying to put myself up to date. For now, I've been able to fix the German manual of Claws Mail so the hydra is able to build packages again.

And now it's breakfast time ;-)

Syndicated 2010-04-10 07:48:39 from Ricardo Mones

xauth magic

While trying to launch claws-mail in my remote ssh-forwarded display I got an:
X11 connection rejected because of wrong authentication error message.
I realized then that while DISPLAY was configured correctly to point localhost:10.0 I was using another user in the screen session, not the one used to ssh in. After some googling for the message seems the usual culprits for this were low disc space (!) and disabled X11 forwarding, which were not my case. There were mentions to ~/.Xauthority permissions, but you don't have such file when you su to another user. So xauth came to my rescue: on the user which logs in you can list authorizations:

$ xauth list
busgosu/unix:0  MIT-MAGIC-COOKIE-1  
localhost.localdomain/unix:0  MIT-MAGIC-COOKIE-1  
busgosu/unix:10  MIT-MAGIC-COOKIE-1  

And in the user you su-ed to, and which doesn't have the file:
$ xauth
xauth:  creating new authority file /home/otheruser/.Xauthority
Using authority file /home/otheruser/.Xauthority
xauth> add busgosu/unix:10  MIT-MAGIC-COOKIE-1  
xauth> exit
Writing authority file /home/otheruser/.Xauthority
$

And you're done, with the same authorization now X11 forwarding works for the other user too :-).

Syndicated 2009-12-28 11:14:45 from Ricardo Mones

Defense of fundamental rights on the Internet

I was going to copy it, but lazy as I am, I think is more interesting to link it, as I'm not the original author and I don't have more much to add, so this is the link to Ana's blog entry «En defensa de los derechos fundamentales en Internet» (in Spanish), hey Ana! ;-)

English readers: if you want to know what this Ana's post is about, read this.

Syndicated 2009-12-20 19:28:56 from Ricardo Mones

Migrating disk

I had in LJ the final story of the failed disk, so, having woken up in the mood of bloggin', it saves me a precious time :-). Lots of console output and boring stuff, you know, but here it goes:

The failing setup were two discs I synced manually from time to time, their partition table:

Disk /dev/sda: 200.0 GB, 200049647616 bytes
255 heads, 63 sectors/track, 24321 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x0003b1cf

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1         122      979933+  83  Linux
/dev/sda2             123         365     1951897+  82  Linux swap / Solaris
/dev/sda3             366        1581     9767520   83  Linux
/dev/sda4            1582       24321   182659050    5  Extended
/dev/sda5            1582        2189     4883728+  83  Linux
/dev/sda6            2190        2554     2931831   83  Linux
/dev/sda7            2555        2676      979933+  83  Linux
/dev/sda8            2677       24321   173863431   83  Linux

And mount points:
/dev/sda1               918322    445462    423864  52% /
/dev/sda3              9614148   5303228   3822544  59% /usr
/dev/sda5              4806904   3629392    933328  80% /var
/dev/sda6              2885780   1107812   1748652  39% /opt
/dev/sda7               918322      8256    861070   1% /tmp
/dev/sda8            171134396 135680768  35453628  80% /home

This setup, appart of the manual sync, had some issues to be addressed:

  • Because of packaging activities /var was always nearly full, so it had to be increased

  • Because of doubling the memory some months ago, there was less swap than current RAM size (2G), also something to fix


The hardware choice wasn't very difficult, as I tend to like Seagate, so balancing price, capacity and availability decided for a couple of ST3500418AS. These are SATA-II, while my motherboard is SATA-I only but aren't they supposed to be backwards compatible? Well, they are, but you have to setup a jumper to lower interface speed, otherwise the disc isn't even recognized by the motherboard.

Buying the discs had some more difficulties. First tried Alternate, but this time they pretend me to pay the SGAE[es] tax for media (which is around 12 euros per disc), despite I clearly explained these were system discs to be mounted in RAID (and the tax is supposed only to apply non-system drives). Phoned them even, but no way, so I finally rejected the discs and went Optize, which doesn't seem to have the supposedly legal problem Alternate has with declaring system discs. They were served on time and for less than 90 euros, so bravo for them :).

After having the bare metal, initially these options for migration were considered:

  • Buy a 2.5 disc, copy current data (a 250 Gb disc is enough), install the new system, copy back

  • Buy a hard disc enclosure for the remaining good disc, install the new system, use the enclosure to copy data back

  • Install new system in one disc (sda), copy data from current disc (sdb), replace old disc with second and setup RAID on a running system


But in the end I got it with a fourth option based on this later one: install a new system with all the RAID setup, disconnect second drive (like if the array had failed), reconnect and copy contents of old drive to new system, restore second RAID drive and add it again to the array, so it gets synced again. Nothing to buy and more fun to see how fast the MD rebuilds the array.

So finally this is the new partition table:
Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000a9eb5

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1         134     1076323+  fd  Linux raid autodetect
/dev/sda2             135         620     3903795   82  Linux swap / Solaris
/dev/sda3             621        2322    13671315   fd  Linux raid autodetect
/dev/sda4            2323       60801   469732567+   5  Extended
/dev/sda5            2323        3416     8787523+  fd  Linux raid autodetect
/dev/sda6            3417        3538      979933+  fd  Linux raid autodetect
/dev/sda7            3539       12170    69336508+  fd  Linux raid autodetect
/dev/sda8           12171       60801   390628476   fd  Linux raid autodetect

And mount points:
/dev/md0               1059264    263360    742096  27% /
/dev/md1              13456532   1703152  11069820  14% /usr
/dev/md2               8649480   1365644   6844464  17% /var
/dev/md3                964408     17632    897784   2% /tmp
/dev/md4              68248448    184216  68064232   1% /opt
/dev/md5             384497716 132355408 252142308  35% /home


BTW, after all I did buy the SATA enclosure for the remaining disc, so I have another 200Gb for pr0n ;-).

Syndicated 2009-10-29 06:24:51 from Ricardo Mones

-bash: /bin/su: Input/output error

That's today's message from bash. Fortunately seem's it's able to spawn it, su command and a bunch of others had not been so lucky.

The ps command is another of the lucky ones, an excerpt (hey! less also works) is highly insightful:

20292 ?        S      0:00 sh -c $SMARTD_MAILER -s 'SMART error (FailedReadSmartSelfTestLog) detected on host: busgosu' root 2>&1 << "ENDMAIL"?This email was generated by the smartd daemon running on:??   host name: busgosu?  DNS domain: [Unknown]?  NIS domain: (none)??The following warning/error was logged by the smartd daemon:??Device: /dev/sda, Read SMART Self-Test Log Failed??For details see host's SYSLOG (default: /var/log/syslog).??You can also use the smartctl utility for further investigation.?No additional email messages about this problem will be sent.?ENDMAIL?
20293 ?        S      0:00 /bin/bash -e /usr/share/smartmontools/smartd-runner -s SMART error (FailedReadSmartSelfTestLog) detected on host: busgosu root
20301 ?        S      0:00 run-parts --report --lsbsysinit --arg=/tmp/fileCJFXti --arg=-s --arg=SMART error (FailedReadSmartSelfTestLog) detected on host: busgosu --arg=root -- /etc/smartmontools/run.d
20302 ?        S      0:00 /bin/bash -e /etc/smartmontools/run.d/10mail /tmp/fileCJFXti -s SMART error (FailedReadSmartSelfTestLog) detected on host: busgosu root
20303 ?        S      0:00 /usr/bin/mail -s SMART error (FailedReadSmartSelfTestLog) detected on host: busgosu root


So /dev/sda is dying, now for real. It gave me some warnings two or three weeks ago, so last week I made a complete backup on its twin disk, using ddrescue, because dd wasn't able to do it without failing.

It's time, again, to seek for a couple of disks which last for almost five years... if possible.

Syndicated 2009-09-25 13:24:42 from Ricardo Mones

Debcamp

So, finally here we are, after a 6 hour travel by car I arrived to DebConf 9 venue on Thursday afternoon.

Weather is marvelously sunny (as expected), but not as hot as the figures may suggest (36ºC at arrival, something less today).

Still a lot of people to come (DebConf starts next week) but nearly about 50 are already here, and growing.

Syndicated 2009-07-18 00:21:42 from Ricardo Mones

64 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!