Skein’s goal is provide easy functionality for rebuilding SRPMS from upstream and import them into github, where they can be built using our koji instance. The process is actually easier than one might think:

• skein request – Request a particular repository be setup on our github organization for the specified package. The package itself should be able to be requested from the SRPM, but that feature is not yet available.
• skein query – To verify the request has been placed, this shows the open queries (by default).
• skein show – For a particular request, show the detail of who requested and the purpose of such a request.
• skein grant – Only an admin can grant the repository. Only members of the admin team on our github organization can grant the repository.
• skein extract – Once granted, the SRPM can be extracted and placed into two basic directories:
• /path/to/package/lookaside/ – contains the archive from the SRPM, usually a tar, tar.gz or zip file. The contents of this directory can then be pushed to the lookaside cache.
• /path/to/package/git/ – contains the spec file, any patches and other sources that are not archives. A Makefile and sources file are also generated along with a .gitignore to provide useful functionality during the koji build

Other functionality is currently under development:

• skein push – Once extracted and committed to the git repository, this pushes the git commits to github.
• skein upload – Once extracted, this uploads the content of the lookaside directory to the lookaside cache at pkgs.gooselinux.org.
• skein import – A combination of skein extract, push and upload, since that seems fairly logical.
• skein build – Albeit mostly complete, it will need to be tested with an SRPM that has been run through this process.

I took a few minutes the other day and created a video of the completed process. I post this here for others to use for their benefit, but also so I can have it in another place besides my laptop.

Skein video

Cheers,

Herlo

What is pydf?

$ yum info pydf

I was also able to send in a patch for the python 2.4 version to the upstream author. He was very happy to receive and apply the fix. The patch is also available in the source rpm.

A nice looking screenshot of the output from pydf is below:

Cheers,

herlo

In July of 2001, I was introduced to a little editing tool many of us now know fondly, the wiki. I was travelling to New Zealand looking for work. During my month’s stay, the fellow I traveled with showed me his wiki-wiki. He explained how collaboration could work and the simplicity of the system made it even great for a one person quick web page. Immediately, I was hooked. When I returned from New Zealand and enrolled in school, my mind quickly went back to this funky wiki-editor thing I’d seen. Being a geek even back then, I promptly installed one.

Fast-forward almost 7 years. We’ve seen the wiki evolve from a little app that could be used to make an entire website of information so grand that even the largest collectors of physical data can’t compete. We’ve seen tools like DocuWiki – the documentation wiki, MediaWiki – which needs no introduction and Tomboy – the little desktop wiki. Many other wiki’s emerged to help people collaborate all around the world. How great a time it was…

This article isn’t about wiki’s, rather it is about collaboration. This article is about a different type of collaboration, one that’s more real-time than a wiki can be. In some ways its more limiting and in others, much less. The feature I’m referring to is real-time collaboration. And the tool that enables this, gobby, and its closely related cousins, sobby and obby.

INTRODUCING GOBBY

Gobby is a collaborative text editor, with a bunch of cool features. While gobby is still young and not quite feature-full, its quite amazing what it can do out of the box. The collaboration abilities of gobby come straight out of the box. One can choose to create a session on the local network, or create a server version, with sobby, where everyone can connect to a centralized server to collaborate. I’d like to also point out this application can also run in Windows according to the authors’ website, though I’ve heard rumors that it doesn’t work as I’ve not personally tried.

To get started with gobby, its easily installed:

# yum install gobby
.. snip ...

Once its installed, gobby will easily load from Applications -> Internet -> Gobby Collaborative Editor. Up pops the window we showed you above, albeit a little more bare. The toolbar is the most important piece here.

There are two distinct features here, plus the ability of a regular text editor. On the left, are the connection buttons, one can join or create a session. On the right hand side, are user and document lists, and a chat button. The left hand side controls how to connect, the right controls once you are connected. Of course, the middle does have tools of a normal editor.

Clicking the Create session button provides this dialog, allowing for a local session to be created and maintained.

This session can be just one person, but is definitely better with at least two. Notice that you’ll need to pick a colour. This feature is what makes it easy to tell who’s edited what parts of every document in gobby.

The other option is to join a session. Joining a session also lists any local sessions currently available.

Once the session is created and/or joined, its just a matter of using gobby like an editor. The fun part about gobby though, is when the collaboration begins. When working on a document, others can work on it as well, at the same time. Which can be confusing, and troublesome the first time you play with this tool. Give it some time and you’ll be hooked.

In addition to creating an obby session with the gobby application, its also possible to create a persistent connection with the sobby server. Unfortunately, sobby doesn’t have features that let it run as a SYSV service, but it is possible to get a server up and running quite easily even still. The organization I run, UTOSF, has one currently up and running at gobby.utos.org. If you want to join up, please let me know and we’ll get you connected.

Take the time to get to know this awesome collaboration tool, and start working with your friends who code, or document or even just for simple brainstorming sessions.  The possibilities are endless.

Cheers,

Herlo

First, install apg:

# yum install apg
.. snip ..
Install      1 Package(s)
.. snip ..
Total download size: 101 k
Is this ok [y/N]: y
.. snip ..
Installed: apg.i386 0:2.3.0b-5.fc8
Complete!

apg does provide several switches which help to provide an easy way to distribute passwords. Recently, I generated random, yet pronounceable passwords for about 30 users of an application I was using. it was quite nice to let the users login and feel safe with my choices of passwords.

To start with apg is quite easy to generate a set of passwords:

$ apg
NatnawmIx
GhisImAv*
Bahiwaihet
adMuhevep
Ombachat
cier]bipt

These passwords are the default set from apg, providing six pronounceable, 8-10 digit, In my opinion, its better to lose a bit of security to make a password easy to remember, than to have a user have to write the password down, more or less defeating the purpose of the password in the first place.

Because of my opinion, (and no, I’m not a security expert by any means, just using common sense), its probably a good idea to have a look at some of the switches provided by apg:

-a : 0 (default) will make the passwords semi-pronounceable, 1 on the other hand, will be pseudo-random

-n : tell apg how many passwords to display

-m/-x : the minimum/maximum length of the generated passwords

Here’s an example of these options in use:

$ apg -a 1 -n 2 -m 7 -x 10

apg has more to give us though. We can use some standard Linux password checking utilities to help us:

-r : checks the generated passwords against a particular dictionary file.  /usr/share/dict/words, for example.

Adding this to our previous example (and removing the -a option) will verify the password doesn’t have any dictionary words:

$ apg -r /usr/share/dict/words -n 2 -m 7 -x 10

The last component is -M mode, which can request/require that a password has a particular set of attributes. Its a bit more complex than the others above. The mode consists of eight letters, S, N, C and L, in both upper and lower case.

S :  must use special symbol set for every generated password.
s :  should use special symbol set for password generation.

N : must use numeral symbol set for every generated password.
n : should use numeral symbol set for password generation.

C : must use capital symbol set for every generated password.
c : should use capital symbol set for password generation.

L : must use small letters symbol set for every generated password (always present if pronounceable  password generation algorithm is used).
l  : should use small letters symbol set for password generation.

As you might be able to tell, the list above is almost directly from the man page for apg. This is on purpose as it is very well explained (and recommended to read each and every man page for any tool used). Many a good trick has come directly from the man pages.

Let’s see these options in use:

$ apg -n 2 -m 7 -x 10 -M SCnL
Hej=Nio
nefMit/

What is noted right away during several iterations of these modes is the fact that rarely, if ever, is a number included. It seems the lowercase modes are not strong suggestions except in the case of “lower case letters”. However, using the uppercase mode values works every time as expected.

apg is a simple, yet effective tool for generating passwords. My hope is that you decide to use more secure passwords in the future with tools like apg.

Cheers,

Herlo