fidzu : Fedora

O Projeto Fedora anuncia que os certificados dos subdomínios *.fedoraproject.org estão expirados. Algum problema ocorreu na monitoria desse prazo de expiração, e agora fomos "pegos de surpresa".

O Projeto Fedora já abriu um ticket para tratar do assunto com toda urgência.

leia mais

31 Jul 2010 1:53pm GMT

31 Jul 2010 4:17am GMT

Uma das paisagens mais bonitas que eu já ví na minha vida foi a vista das cordilheiras dos andes. Tenho viajado para o Chile e Argentina há vários anos, mas confesso que me emociono a cada vez que subo em uma estação de esqui ou faço algum passeio pelas montanhas.

Desta vez viajando para participar da FUDCon em Santiago tive mais uma vez essa visão privilegiada!

A paisagem é realmente fantástica, seguem algumas fotos que tirei da janela do avião ao sobreovar essa maravilha de DEUS!

31 Jul 2010 4:01am GMT

Thought I'd read up some QC (I don't feel like working at the moment).

In this comic strip he says:

Before you send me angry, tear-stained e(mo)mails, let me just say that you are perfectly entitled to enjoy listening to any of the bands that Marten and Faye are wishing to assault in today's strip. I would never begrudge someone their taste in music. It's such a subjective thing that there really is no "right" or "wrong" when it comes to one's listening habits.

The flipside of that coin, though, is that I AM perfectly entitled to make fun of emo bands for being Goddamned crybabies who take themselves too seriously.

+1 to that!

31 Jul 2010 3:41am GMT

So Mike McGrath announced repos.fedorapeople.org. Pretty cool, right? I updated the Etherpad packages for F13 and moved them there. Want to try them out? Awesome. Follow this quick guide:

31 Jul 2010 12:20am GMT

New Home Office all done! Complete with beer and light sabers. Big brown dog there when he feels like it.

31 Jul 2010 12:18am GMT

...to an F13 installation near you. Soon. We need a little feedback from you, though. Specifically for the following ativities.

30 Jul 2010 11:51pm GMT

Se state usando Fedora 13, a causa di alcune recenti update è possibile che non stiate più ricevendo notifiche degli aggiornamenti disponibili e sia impossibile effettuare l'aggiornamento con il tool grafico (PackageKit)

Ovviamente il problema è stato prontamente risolto ed i relativi pacchetti aggiunti nei repository intorno al 22 Luglio scorso, ma per poterli installare è necessario utilizzare il tool da linea di comando "yum" da root come segue.

Per aggiornare tutti i pacchetti
yum --skip-broken update

Per aggiornare solo i pacchetti relativi al problema in questione
yum -y --skip-broken update gnome-packagekit selinux-policy

Tutti i dettagli nell'annuncio inviato dal nuovo Fedora Project Leader, Jared Smith.

30 Jul 2010 10:48pm GMT

Anunciamos a criação de uma nova lista de emails oficial, específica para o desenvolvimento do Fedora para membros do Brasil.

leia mais

30 Jul 2010 9:48pm GMT

I'm working through the issues getting the unit tests to run cleanly. Here's my setup:

My Laptop run F13. I have a git repo at ~/devel/freeipa
After doing a git checkout, plus possibly a git clean -fd, I run

make rpms

The rpms I then deploy to a virtual machine I have running in kvm on my laptop. The VM has the hostname of ipa which is resolvable from the vm via dnscache. This means that the value of the DHCP address assigned to the vm is assigned to the hostname inside /etc/hosts:

192.168.100.12 ipa.ayoung.boston.devel.redhat.com ipa

Here's my deployment script:

export IPASERVER=ipa
export IPAROOT=/home/ayoung/devel/freeipa
export IPAPASSWORD=
export IPA_RPMS="ipa-client ipa-server-selinux ipa-python ipa-server ipa-debuginfo ipa-admintools"
ipa-pushd(){
        pushd $IPAROOT
}
ipa-uninstall(){
         ssh root@$IPASERVER "ipa-server-install -U --uninstall -p $IPAPASSWORD"
}
ipa-build-deploy(){
        ipa-pushd
        git clean -fd
        make rpms
        ipa-uninstall
        ssh root@$IPASERVER "rpm -e $IPA_RPMS"
        IPATEMP=`ssh root@$IPASERVER mktemp -d`
        scp dist/rpms/*rpm root@$IPASERVER:$IPATEMP
        echo rpms uploaded to $IPATEMP
        ssh root@$IPASERVER   "cd $IPATEMP ; ls | xargs  yum localinstall --nogpgcheck -y "
        ssh root@$IPASERVER "ipa-server-install -U -r AYOUNG.BOSTON.DEVEL.REDHAT.COM  -p $IPAPASSWORD  -a $IPAPASSWORD -u admin" &&\
        zenity --info --text  "rpm build and deploy completed.  Better check for errors."
        popd
}

I have all this, plus a few more functions, in a file that I source in at the start of each bash session.

Lets take it by the numbers:

Lines 1-4 are variables used elsewhere in the script, for the directory that holds my source and for the server host name. I've elected not to show the value of my other variable, $IPAPASSWORD, although I use a throwaway password for this that is only for development machines.

The pushd based function on line 5 merely gets me statement completion, but I use it constantly. If it is stupid but it works…

The uninstall line is often useful on its own. Like most standalone functions, this one started off inline. I extracted it into its own function once I decided I wanted to be able to call it on its own.

line 13: WARNING! git clean -fd will delete any files that git does not know about. I make it a point to, at a minimum, run git add for any files I have added to the the repo. Yes, I've burnt myself on this one a few times.

Line 16: Although I am a fan of running rpm -U, our rpm naming scheme is based off the hash from git, and is not monotonically increasing. This instead uninstalls the old set of rpms, and then lines 17 creates a temp directory used in line 18 for uploading the newly built rpms. Note that line 17 captures the name of the directory created, a useful technique for maintaining some semblance of state over multiple ssh calls.

Line 20: Use Yum to install the rpms. While it might be tempting to do an rpm -U, using yum this way allows me to install the dependencies from the appropriate repositories. Aside from the 389 Directory server, I get python-nss from a team specific repository as well. Yum ensures I have the lates builds of both.

Line 21: Run the ipa-server-install script in untended mode, providing the required passwords on the command line. Good for testing, probably not how you would want to do it for a live install.

Line 22: Use zenity to report that all has been completed. This gives a modal popup window that also causes the bash shells icon in my toolbar to change color, snapping me out of my torpor, ready for action.

I test that the server is up and running with:

ssh root@ipa

kinit admin

ipa user_find

In order to run the tests on the vm, I have exported my devel directory in /etc/exports:

/home/ayoung/devel *(no_root_squash,rw,insecure,sync)

I'm not a fan of making it read/write, but for the tests, I (suspect I) need to be able to write into that directory. The no_root_squash is also required as I run the tests as root on the vm.

On the vm, I mount the devel directory via an entry in /etc/fstab:

192.168.100.1:/home/ayoung/devel /home/ayoung/devel nfs rsize=8192,wsize=8192,timeo=14,intr

The last setup issue prior to running the tests is to run

export IPASERVER=ipa
ipa_pushed
make
make -C install/po test_lang\
popd

The second make command is only necessary to get the language file populated for the translation test, but is included for completeness.

To run the tests, I have two consoles windows open on the vm. In both, I start with

pushd /home/ayoung/devel/freeipa

In one I run the lite-server with debugging:

./lite-server.py -d

and in the other I run the tests:

./make-test > /tmp/test.log 2>&1

At this point, I still have errors. I'll update this post once I get the tests running at 100%.

30 Jul 2010 9:16pm GMT

Hace un par de días descubrí en mi servidor de IRC unos archivos "raros" en el /tmp, que obviamente yo no había generado:

-rw------- 1 ircd ircd 17251 Jul 8 09:10 robot.txt
-rw------- 1 ircd ircd 17251 Jul 8 09:10 robot.txt.1

El contenido de estos archivos era un script.
La explicación de mas o menos que es lo que hace dicho script, la pueden ver en este link

En definitiva, unrealircd reporto hace poco (el 12 de junio), en su foro el problema. Al parecer, alguien cambio el .tar.gz en los mirrors de unrealircd por uno que contenía un backdoor (esto paso en Noviembre 2009), el cual permitía a cualquier persona ejecutar cualquier comando como el usuario con el corría el ircd (esos nos sigue enseñando a todos que no hay que correr servicios como root). Así que alguien, muy vivo, exploto esta falla en nuestro IRC (irc.xterm.com.ar), pero al parecer mucha maldad no hizo.

Si tu unrealircd esta comprometido o no, se puede probar de estas 2 formas:

Verificar el checksum md5 si todavia tienen el .tar.gz:
(MALA) es: 752e46f2d873c1679fa99de3f52a274d
Versión Oficial (BUENA) es: 7b741e94e867c0a7370553fd01506c66

La otra forma es pararse en el directorio donde lo compilamos y correr:
grep DEBUG3_DOLOG_SYSTEM include/struct.h
Si, el resultado son 2 lineas entonces tenemos la versión mala, si el resultado es nada entonces es la buena.

La solución es re-descargar el unrealircd y validar que sea el correcto por GPG o MD5/SHA1.

Deberé seguir confiando en unrealircd? o deberíamos mudarnos a otro?

English:

Some days ago I found in my IRC server, a couple of "weird" files in the /tmp directory, that obviously I did not create.

-rw------- 1 ircd ircd 17251 Jul 8 09:10 robot.txt
-rw------- 1 ircd ircd 17251 Jul 8 09:10 robot.txt.1

The content of these files was a malicious script.
The explanation about what does this script does can be reached at this link

unrealircd reported some days ago (June 12) in their forum the problem. Apparently someone changed the .tar.gz package in their mirrors for one that contained a backdoor (this happened in November 2009). This backdoor allowed any person to run any command with the privileges of the user running the service (this is still remember us that we must not run services as root) .
Someone exploited this bug in our IRC (irc.xterm.com.ar), but apparently nothing bad happened for us.

If you need to check if your unrealircd is compromised or not, you can try this with one of these two ways:

Verifying the MD5 checksum of the .tar.gz package:
(BAD) is: 752e46f2d873c1679fa99de3f52a274d
Official version (GOOD) is: 7b741e94e867c0a7370553fd01506c66

The other way, is change to the directory where we compiled the source code and then run:
grep DEBUG3_DOLOG_SYSTEM include/struct.h
If it outputs 2 lines, then you're hacked.
if it outputs nothing, then you're good.

The solution is re-download unrealircd and validate that it's the good package by checking GPG or MD5/SHA1 checksum

May I continue using unrealircd? or do I need to move to a new one?

30 Jul 2010 6:04pm GMT

A little trick to find out your outgoing IP address through a DNS query:

iarlyy@wolfman $ dig myip.opendns.com @resolver1.opendns.com +short
66.7.199.108

This is it!… Happy Linuxing!

30 Jul 2010 4:13pm GMT

RPM of new version 0.43 of libmemcached the library to communicate with memcached servers is available in remi repository for Fedora ≥ 6 and EL ≥ 4. It's also available in rawhide (and fedora 14) repository.

As always: yum --enablerepo=remi install libmemcached This library is required by the new memcached PECL extension (an alternative to memcache) in active development phase. As this new version breaks ABI (with previous 0.37), I don't plan any update in the fedora 13 repository. ABI is stable since.0.40.... Lire libmemcached-0.43

30 Jul 2010 3:36pm GMT

(If someone can translate and post this to the zh-language Fedora Planet, that would be awesome!)

I'm about to board a plane to Shanghai - I'll be in China for a week devoting my time towards building up Fedora activities and presence in the region. If you're in FZUG, in the area, or interested in the region, please let me know! I will be in #fedora-zh all week (I usually lurk there anyway) and trying to improve my (very basic) Mandarin skills, but will probably need a lot of translation help.

This trip was originally supposed to be a POSSE (more on that later) but that was unexpectedly canceled at the last moment - it's actually a good thing, though, because we'll have more of a chance to get to know what's happening in the area.

One area I'm personally interested in is education, mostly at the college level - for instance, it would be great to see a POSSE (workshop for professors interested in getting their students involved as contributors to open source communities) in China sometime in the next two years, and I would love to talk with people about how we can make this happen.

However, my first priority on this trip are the Ambassadors and folks working on the ground for Fedora in the region. How can we do a better job of getting you resources, how can we get more publicity on Planet and Ambassadors-list regarding what is happening in the region? Do we have a lot of packagers, or translators, of $SKILLSET in the region that we should organize a FAD around? Who should we talk to? Where should we go? Do people want to meet up for dinner some evening?

In other words, what are Linux users in China passionate about, and how can Fedora help them? Blank slate.

30 Jul 2010 3:07pm GMT

Got bored of having to run 'make install' when hacking on Evolution, partly because libtool insanity makes it take too long - as for some reason it relinks everything as it installs it. Perhaps that was needed for FORTRAN77 programs on OSF/1, but it isn't needed on my modern Linux system. I hate libtool. But even without that, re-running 'make install' every time you change a line of code is a pain.

For a while I took to manually symlinking the libraries and executables I was working on, from my build directory into their installed locations. But I kept missing some out and that was a pain too.

My current solution, which excited mbarnes sufficiently that I felt I ought to share it more widely, is to re-run autogen.sh with the --enable-fast-install argument, then build it and run 'make INSTALL=install_symlink.sh install'. Then all files get installed as symlinks instead of being copied, and all I have to do is hack code, type 'make', and run evolution again.

The script is a dirty hack and there are much better ways to do it - some of which would even cope with filenames that have spaces in. But it works for me, and makes Evolution hacking a little easier.

30 Jul 2010 3:03pm GMT

I bet you're asking, where did the Fedora chromium packages go?

Don't worry, they just moved to a different location. To get them, go here:

http://repos.fedorapeople.org/repos/spot/chromium/

There is even a pre-made fedora-chromium.repo file that you can drop into /etc/yum.repos.d/ and go!

30 Jul 2010 2:57pm GMT