It seems an external site was attempting VPN access into our corporate network.  The problem the external site was hitting was that they couldn’t initiate a session FROM their network…but someone from our location could initiate a connection TO their network.  They used a Linux box to provide them VPN, Firewall, and proxy services.  Now, any Linux admin worth his or her salt would have immediately known that being able to VPN back into a site but not VPN out of a site means that the firewall doesn’t have the right ports open and/or forwarded.  This should have been an easy fix…but the guys at this external location evidently didn’t posses this knowledge.

Instead of blame falling on the improper configuration, open source was blamed as a whole.  My colleagues stated that those “free tools people use never stack up to paid ones” and that “you get what you pay for…and if you don’t pay for it you don’t get it”.  So according to these guys:

• Free = poorly designed, less than good software
• Paid = better designed, wicked awesome software

Which of course, you and I know is a bunch of hooey.  And this is what some of the smartest guys I’ve had a chance to work with state about Linux and open source.  Makes me really wonder if they know their Cisco stuff is often times Linux and open source as well.  I guess maybe I should tell them sometime.  Either way, Linux still has a long way to go to garner the acceptance it should have.

Overheard at the Water Cooler originally appeared on Yet Another Linux Blog on July 7, 2009.

One of the things that team docs here has known for a while is that the rPath wiki is a fantastic tool to leverage for documentation. It’s quick. It’s easy. It allows engineers to contribute directly to the wiki. It allows community members to contribute to to the wiki.

We’ve also known for a while that this tool has a major caveat…and that is that versioned documentation is costly. For example, if we had say version 1.0 documentation of a project at wiki.rpath.com/v1/productname and version 2.0 came out, we’d have to maintain 2 separate documents with the same information in two different URI’s and 2 different name spaces. With each addition of namespace and project version, updates would be more costly and time consuming.

It’s also a bad thing that a user can search the wiki…and have the possibility of getting results from versions that they are not using…possibly information and behavior of products that no longer applies.

So how do we plan on combating this? There are a couple of phases of plans that we’ve been thinking about. The first of these is to move all product related guides (Administrative, User) offline into docbook format (pdf, html). We’ve begun testing this idea already.

This buys us the ability to keep versioned documentation separate from the wiki which empowers customers by giving them only the documentation they need and not requiring them to wade through search results to get the documentation they need.

This also is good for the community. Why? Because community docs will remain on the wiki and product documentation will be separated from it This means that documentation on using open source tools like Conary and working with rBuilder Online will be separate from rPath products making things easier to find and easier to contribute to.

The next phase of the plan after separating product specific documentation is to provide a central repository for those offline docs. This is further down the road and will only take place if product documentation has been moved offline. When this phase hits, there will be a handy website that serves as a central repository for all documentation, whether product based or community based. Currently, there are no plans to move community documentation from the wiki (Conary, rBuilder Online, rMake).

So, those are some of the updates we’ve been talking about doing. Nothing is set in concrete but we’re continuing to stay busy by keeping the information readily available to both community and customer

rPath Documentation Status Update originally appeared on Yet Another Linux Blog on June 12, 2008.

Why another package manger? Isn’t there already too many of these out there? Why use Conary when I can apt-get? Apt-get is soooo much better. Dpkg gives you sooooo much more than anything could possibly give you. Conary is still beta quality…rpm and deb are much more developed mature.

If the person(s) asking the questions above actually understood what Conary is and CAN do…they would see this is a very limited view of Conary. Not only is conary a package management system vis-a-vis a system that manages EVERY single package of software on your system…it is also a powerful version control system for software packages and packaging. It’s an enabling mechanism for packaging software quickly and easily.

I’d like to go over some of the things I think are great about Conary…clear up some of the “why is this needed” speak by showing how Conary actually gets things right and the common problems experienced by other package managers that it solves.

How Conary Organizes Packages

If you use debian or rpm repositories…you know that inside a repository directory “stable” (as an example) are all the stable packages for your distribution. The packages are versioned according to their upstream version (if the repository maintainers are sane) and maybe arch and revision number. This is done by hand. It is managed by hand. If developers/packagers cross names between repositories you are brought into dependency problems. To illustrate this concept, if you and I both packaged firefox3 and named it accordingly…and someone used both your and my repository…our versions would conflict because the packaging system wouldn’t know which one to install.

Conary takes the manual operation from this…if you use a Conary based system, your repositories ARE VERSIONED. In other words, the repositories aren’t static directories that contain a bunch of packages…they are versioned branches that contain components of software.

These components (packages) are also versioned according to upstream version…but revision is handled automatically by Conary…no manual process. This eliminates the possibility of having two packages named the same exact thing in different repositories. In other words, if Joe Schmoe is packaging Liferea for his apt.joeschmoe.com repository and names his package the same thing as say Joe Smith’s package for Liferea in his apt.joesmith.com repository we run into problems. With conary this NEVER WILL HAPPEN…EVER. This kills about 90% of dependency problems all together.

But what about arch? Arch is architecture…32bit or 64bit…PPC and more. Once again, you’re bit by the possibility of conflicting names across repositories. You’re also limited in the name because a developer has to put the architecture INSIDE THE NAME. Take a look at liferea as an example: liferea-1.2.2-2.el5.rf.x86_64.rpm. Is this easy for an end user to understand? Is it the same as liferea-1.2.2-2.el5.rf.x86-64.rpm?

Conary takes a different approach. Each package has a ‘flavor’ that it is ‘cooked’ (committed) in. There may be a 64bit flavor, 32bit flavor, Xen flavor, and so on. This flavor is visible to the user only if the user requests to see it…and it is NOT inside the name of the package. The package is still called, simply enough, liferea. Revision number, arch, upstream version, etc…are all handled automatically by Conary.

You can see how creating and maintaining software would rely less on a manual process and more on automatic source controlled one with Conary. You can also see how organized Conary is with its packages.

Sources.list Not Needed

Conary is smart enough to remember where you installed what package. There is no need to keep a sources.list. So if you install the package balsa (a Gnome mail client) from my personal repository the command would be:

sudo conary update balsa=caffeine.rpath.org@coffee:venti-1

So now what? Do you have to add caffeine into a sources.list somewhere? Nope. Conary remembers where that package came from and when an update is available later it will find it and notify you. Let’s say you did the same thing for a hypothetical repository for deb or RPM…you’d add in the repository address for where balsa is at. Then you inherit ALL packages listed at that repository…not just a single package. There once again may be problems with package names, versions, and now sources.

Conary elimiates this problem for you as well. A single package is taken from that repository and since the repository is versioned, conary knows where it came from. It knows that it doesn’t need anything else from that repository unless you tell it to install more.

Problems With RPM and Deb

The real problem I see with deb and rpm is monolithic dependency resolution. This is the term I use to describe what happens when you go to install one package and you get over 10 more packages as dependencies. Dependency resolution in RPM and Deb is left up to the developer to find when creating packages.

When packaging software with Conary, dependency resolution is automatically done FOR you. When you ‘cook’ a package, it calls out what dependencies you need to add to your ‘recipe’ (comparable to rpm spec file).

Another important characteristic of deb and rpm is that when you update a package, the old version is completely removed from your system. This means that if a program depends on another that is being removed, you’re out of luck unless it was flagged as a dependency (manually). As you can imagine, large packages like openoffice take forever to upgrade AND packages depending on one another for specific versions might find they have problems interacting. With conary, dependencies are done at the file level…so only the file(s) that requires updating is updated. This saves bandwidth for downloading and saves time for upgrading. It also allows you to get dependency resolution honed to specific files instead of just specific packages. This means that distros CAN become much smaller…that is, if you were making a liveCD and wanted to trim it down to under 200MB you could do so very easily with Conary’s fine tooth dependency resolution and packages that are componentized.

Rollback to Previous

Conary operates using something called changesets. It looks at what is on your system for software and what you want to install and creates a changeset (like a diff) between the two states. This changeset is then installed by the package manager…it reads it, fetches the software the changeset says it needs to install…and then installs it.

What if you installed a group of packages that you don’t want installed anymore? What if something you installed doesn’t work as expected? Rollback

sudo conary rollback #

where # is the number of rollbacks you would like to rollback to. Each installation action is considered one numbered change for conary. It tracks each installation/removal action and numbers it in a list. You can therefore return to a previous state on your system with ease. See Conary Rollbacks for more information.

Summary

I’ve covered quite a bit of information here…enough for a discussion I’m sure. Are there still areas about Conary you’re unsure of? Leave me a comment. Part II will be coming soon that will discuss more topics about Conary and Foresight Linux. I’d like to base Part II on answering questions from the readers.

Foresight Linux and Conary Part I originally appeared on Yet Another Linux Blog on April 23, 2008.

Those of you interested in helping us develop, package, or use KDE are welcome to join us in IRC #foresight-kde freenode.  Plans are to build a 3.5.9 Stable version and wait until 4.1 is released to push out a 4.1 version.  Of course, we’ll have 4.0.X builds available for testing and fun all the while   Please, lend us a hand and file those bug reports!

Foresight KDE Alpha-Alpha-Pre-Alpha-Pre Screenshot originally appeared on Yet Another Linux Blog on April 22, 2008.

I used to use Lightning for my google calendar in versions before .7…

When .7 came out, it caused Thunderbird to rocket memory usage above 80% which brought my computer to a screeching halt.  I figured I’d not use it until next version (and submitted a bug report as well).

Today I downloaded .8 in hopes it would work better.  It doesn’t.  Memory usage still skyrockets when attempting use the google calendar (provider addon) and the remember mismatched domains add on with it (otherwise you’re unable to connect or get a popup every time you view).

Is it one of these plugins causing it?  Is it Lightning?  I’m leaning toward the latter…even when uninstalling the extensions, I still get memory usage skyrocketing.  Either way, syncing your google calendar with Lightning isn’t a very smooth thing to do if it causes your Linux desktop to screech to a halt.

I guess there is always evolution with built in google calendar support.  Anyone else getting these problems?

At work, we use Zimbra for emailing.  I use Thunderbird with IMAP as my desktop client.  I’ve also seen that as of Zimbra 5.0 RC2, they will have the ability to sync with Lightning.  Good news!  Now if Lightning would stop leaking!

Thunderbird and Lightning .8 originally appeared on Yet Another Linux Blog on April 7, 2008.

Even if you’re not a Foresight User and are just curious about the Conary System Manager, Software Appliances, or software packaging…it would be a great boon to understanding how these things give Foresight an edge over most distros.

Signup on the wiki page (add your name) to attend and we’ll see you there

Foresight Users and Developer Conference 2008 originally appeared on Yet Another Linux Blog on March 11, 2008.

No package exists for RealPlayer in the repositories, so head over to Real.com and download the .bin file. After the .bin file has been downloaded, use the following commands to install:

chmod 755 RealPlayer10GOLD.bin && sudo ./RealPlayer10Gold.bin

In the terminal, it will ask you what directory you’d like to install RealPlayer into. I chose /opt/RealPlayer (you’ll have to type it in) because I’d rather have the files installed there than in my home directory, which is where I downloaded the file to. After this, you’ll have a shiny, new shortcut inside Applications >> Sound and Video >> RealPlayer. Click on this to launch the program and follow the wizard.

The wizard will setup the Mozilla (firefox) plugins for you but they still won’t work solidly. This is because mplayer is overtaking the player duties for real media formats. To change this, gedit ~/.mplayer/mplayerplug-in.conf and change these entries as shown below:

enable-rm=0enable-smil=0enable-helix=0

Save and close that document. You’re set Restart Firefox and go to real.com and test out the player capabilities.

Installing and Using RealPlayer on Foresight Linux originally appeared on Yet Another Linux Blog on February 26, 2008.

Moving on, I was ANNOYED by the fact that you have a small arrow “” that appears beside any image that references an external URL or any link that does the same. This is fine to let people know that links will take them to a different page…but what I was trying to do was to make a PDF Icon have the same link as the URL it was sitting beside:

So in the above image, if one clicked on the PDF icon or the “Application to Appliance: A Hands-on Guide (PDF)” the PDF would download.

Mediawiki doesn’t provide a fantastic way for you to do this. However, after some snooping around via google, I found a fairly easy way to make things happen.

How to Do This

First things first. Open up LocalSettings.php and make sure to set $wgAllowExternalImages = true; if it’s not done already.

Next get the full URL link to the thing you want downloaded…in my case, a PDF. Then, get the URL for the image you want to display/link. What I did was upload the icon to the wiki and then right click on the icon and ‘view image’. Now let’s put them together:

[http://example.com/wiki/uploads/yourdownload.pdf http://example.com/wiki/images/Pdficon_small.gif]

Just after this will go the actual internal link…because the above is only for the icon. So you’d place your double bracket link just after this single bracket one.

[[Media:yourdownload.pdf|Title of Your Download]]

Now that you have both of these completed, you must encapsulate them in a span class to remove the arrow formatting. Add the following before the single bracket above:

<span class=”plainlinks”>

Then close out the span at the end of the double bracket wiki markup above:

</span>

Putting It All Together

So, to summarize, you’d have the following:

<span class=”plainlinks”>[http://example.com/wiki/uploads/yourdownload.pdf http://example.com/wiki/images/Pdficon_small.gif][[Media:yourdownload.pdf|Title of Your Download]]</span>

Seems like a lot of stuff to get a simple image link right? Yes it is. But it works and I don’t have to install an extension to do it (I’m not fond of extensions). Remember also that you can call that span class plainlinks for other simple external links as well to remove the arrow Hope this helps someone in need…I know it helped me.

I would like to give special thanks to Distributedresearch.net which contains the meat and potatoes of this entry. What I’ve done in the example above is make it generic and give a practical example of how I used Andy’s original post.

Mediawiki: Remove External Arrow from Links originally appeared on Yet Another Linux Blog on February 7, 2008.

The problem with issue tracking systems is they have workflows of their own and often are impartial where they don’t need to be . Wouldn’t it be nice if there was a place where like users of software could come together to ask questions and help each other reach conclusive answers? Hence, the rPath Forum was born.

Stef created the Simple Machines Forum Appliance, which you can install and run in various formats such as VMWare, Xen, ISO, RAW, and even a LiveCD (in x86 and x86_64 bit flavors!). What a wonderful concept…to be able to quickly download and deploy a forum using nothing but a virtualized environment

As some of you know, I’ve chose Simple Machines in the past at MyPCLinuxOS and PCLinuxOS proper to power those communities. Stef and I are excited to power the rPath community with this same wonderful software.

If you are a packager, appliance developer, Foresight Linux user, or are just interested in our products and technologies such as Conary and rMake…come on over to the rPath Forum and register. Drop us a line and say hello

The rPath Forum goes Live! originally appeared on Yet Another Linux Blog on February 1, 2008.

sudo conary update gmrun

I’ve patched the default gmrunrc file so that when it executes, it places itself toward the top right hand side of the desktop. To override this, create a .gmrunrc from the default.

cp /usr/share/gmrun/gmrunrc ~/.gmrunrc

alter the left and top values to move it around on the screen. Width may also be adjusted. You can also use openbox to bind this to Alt-F2 or a key combo of your choosing. Open up ~/.config/openbox/rc.xml and add the following in the <keyboard> section:

<keybind key="A-F2"><action name="execute"><execute>gmrun</execute></action></keybind>

There are also some built in macros for using gmrun that can be found on the homepage here. it’s quite a handy tool and works quite well for openbox Screenshot showing updated nitrogen and gmrun below:

gmrun and openbox originally appeared on Yet Another Linux Blog on January 26, 2008.