|
|
Index: Home | What Is Izumi | Linux Tips | OpenBSD Tips | FreeBSD TipsThis page contain several tips for using Linux. I use this mostly as reminders of commands that I found useful. There's generally nothing here one couldn't learn by searching on the net or reading the man pages, which is generally how I got the commands in the first place.
To convert mbx to mbox, one used to use mbxcvt from the imap-utils package.
This is now mailutil from the uw-mailutils package.
# apt-get install uw-mailutils => installes mlock, libc-client2002edebian, uw-mailutils
To convert to an mbx format:
$ mailutil copy OLD_MBOX "#driver.mbx/NEW_MBX"
To convert to an mbox format:
$ mailutil copy OLD_MBX "#driver.mbox/NEW_MBOX"
The format of the old file is seemingly discovered on the fly.
Darn... new kernel.
Patch usbserial:
# cd /usr/src # mv linux-source-2.6.15-2.6.15 linux-source-2.6.15-2.6.15-older # apt-get source linux-image-2.6.15-51-686 => or $ sudo apt-get source linux-image-`uname -r` => Note: it's reallyapt-getsource with linux-image! => Do not mix with "apt-get install linux-source-...", it's really not the same. # cd linux-source-2.6.15-2.6.15
# cat debian/config/i386/config debian/config/i386/config.686 >> .config # make modules # (patch drivers/usb/usb-serial.c as explained by Junxion) # make modules # cd /lib/modules/2.6.15-51-686/kernel/drivers/usb/serial
# cp /usr/src/linux-source-2.6.15-2.6.15/drivers/usb/serial/usbserial.ko . # vim /etc/udev/rules.d/90-evdo.rules => add maxSize=2048 to the modprobe usbserial options # vim /etc/modprobe.d/options => add maxSize=2048 to the modprobe usbserial options # rmmod usbserial # modprobe -v usbserial vendor=0xc88 product=0x17da maxSize=2048
VMWare Player:
# apt-get install linux-headers-2.6.15-51-686 # vmware-config.pl => What is the location of the directory of C header files that match your running => kernel? [/lib/modules/2.6.15-51-686/build/include]
This is not really a Linux tip, more like an Apache tip. But nowadays, LAMP servers are ubiquitous so it's almost synonymous.
So anyway, say your web site at http://www.example.org is fully password-protected,
even with something simple like AuthType Basic. And even your root dir is
protected, even /index.html is not accessible.
And you want to use the excellent
Google Webmaster Tools but in order to do so
you have to let the Google servers verify you own the web site (as in, you are the
webmaster so you have control over its content.) Now this is done in two ways, either by
adding a meta tag to your index.html or by adding a magic file in the root dir.
The problem is that since all your site is password protected, the Google servers
fail to verify it -- they can't get the index or the magic file.
A typical solution is to let the root /index.html unprotected and use it as a portal.
Either you make it part of the web site as a login page, or you simply add the meta data
and use a redirect.
However if you really want the index to be hidden, you can use the "magic file"
method and make it so that the specific magic file is not protected by your
AuthType Basic directive. Note that the magic file has a name such as
googleBunchOfHexNumbers.html -- its content is irrelevant, the Google server
just wants to see a 200 "OK" status code when trying to access it. However the Google
server will also try to access an noexist_SameBunchOfHexNumbers.html and it wants
to see a 404 on that one. A 401 (auth failed) on the noexist file won't work.
In my case, using a .htaccess, I have an AuthType in there but I don't know how
to "disable" it on a given file. Ideally I'd like an AuthType None directive in a
<Files> section. So instead I came up with this in ==/.htaccess=:
FilesMatch "^.*GOOGLE-HEX-NUMBERS-HERE.html"> Allow from all Satisfy Any </FilesMatch> AuthType BasicOrDigestOrWhatever AuthName "My Lamp Server" AuthUserFile /blah/users AuthGroupFile /blah/groups require whatever
That this does is that it applies the authentication scheme to the whole root dir.
But before that, it will all the specific Google files with an Allow from all close.
Ordinarily, this clause is mixed with the authentication one so that both must match
but you can make it an or by using Satisfy Any: Satisfy that the file request
comes from anywhere or that authentication is successful.
$ sudo apt-get install g++ $ su apt-get install libfuse-dev libssl-dev $ su apt-get install fuse-utils $ wget http://arg0.net/vgough/download/encfs-1.3.2-1.tgz $ wget http://arg0.net/vgough/download/rlog-1.3.7.tgz $ tar xvzf encfs-1.3.2-1.tgz $ tar xvzf rlog-1.3.7.tgz $ cd rlog-1.3.7 $ ./configure && make && sudo make install $ cd ../encfs-1.3.2-1 $ ./configure && make && sudo make install
$ sudo mkfs.ext3 /dev/hda2 $ sudo mkdir /backup $ sudo vim /etc/fstab + /dev/hda2 /backup ext3 defaults,errors=remount-ro 0 1 $ sudo mount -a -v
There are more tips on HOWTO: Encrypted directory with EncFS.
$ sudo adduser <your username> fuse # Requires a logout of the user to work $ sudo modprobe fuse # Load kernel module once or... $ sudo vim /etc/modules # add fuse to load it automatically
EncFS then needs one directory wit the encrypted files and one mount point for the clear versions.
To create or mount the crypted fs:
$ encfs /backup/.crypted /backup/clear
To unmount:
$ fusermount -u /backup/clear
Issue: What to watch a large bunch of DVD episodes on a MythTV; you've got a large disk so why not extract everything from the DVDs onto the disk instead of swapping these DVDs all the time?
The process I use is sort of like this:
avimerge) so instead I actually merge after the down conversion.avimerge to join the split files.Using MediaCoder with these settings:
Which gives us:
# ".\codecs\ffmpeg.exe" -y -i "D:\Ralf\tubby-c-6_3.vob" -f avi -vcodec h264 -b 700000 -r 25 -aspect 4:3 -acodec mp3 -ab 96 -ar 44100 "D:\Ralf\tubby-c-6_3.avi"
And what FFMPEG has to say about it:
Input #0, mpeg, from 'D:\Ralf\tubby-c-6_3.vob': Duration: 00:23:39.8, start: 0.190311, bitrate: 2468 kb/s Stream #0.0[0x80]: Audio: ac3, 48000 Hz, stereo, 256 kb/s Stream #0.1[0x1e0]: Video: mpeg2video, yuv420p, 352x576, 2130 kb/s, 25.00 fps(r) Output #0, avi, to 'D:\Ralf\tubby-c-6_3.avi': Stream #0.0: Video: h264, yuv420p, 352x576, q=2-31, 700 kb/s, 25.00 fps(c) Stream #0.1: Audio: mp3, 44100 Hz, stereo, 96 kb/s Stream mapping: Stream #0.1 -> #0.0 Stream #0.0 -> #0.1 [h264 @ 0095A620]using SAR=24/11 [h264 @ 0095A620]using cpu capabilities MMX MMXEXT SSE SSE2 3DNow!
This converts at about 20 fps on an Athlon 64 3500+ and I get the files down from ~420 MB to ~150 MB. Result works fine with MythTV.
Of course MediaCoder is just a fancy shell over FFMPEG and a lot of over video/audio tools. It is however extremely convenient since the installer brings all these tools as Cygwin executables, whereas it's a pain to compile them oneself (I never myself managed to compile FFMPEG with x264 support under Cygwin, it's just too much pain and it's quite an unnecessary distraction when all I cared was to get some video files right away. YMMV.)
There are two problems with MediaCoder though. The first one is that it's again yet-another Cygwin-based app which installs some Cygwin DLLs (just like the NX Client for example.) So if you happen to already have Cygwin installed both MediaCoder and your Cygwin install will be broken if don't tweak it around (I haven't tried but I think doing the same trick as NX should work, that is locate the new DLLs and trash them before they run and register themselves.) The second issue, which is minor, is that it's a bit of a nagware; each time you run MediaCoder is actually opens a web browser to display its homepage and ask for a donation. I have no problem with freeware asking for donations but I find nagging to be a bit objectionable -- it screams "I make it free but really I want to get paid for it".
As explained earlier, one of the points of SVN is that tags and branches are just regular directories in the repository that actually contain a full mirror of the trunk.
For the repository, these tags and branches are free in the sense that they are "virtual" and data is not duplicated unless it has changed.
However if you have a complicated repository with hundreds of tags, when you do a checkout you'll end up with the trunk and then 99% of duplicates in the form of tags or branches -- because your local file system doesn't know these are shallow copy-on-write duplicated data.
The usual way around is to only checkout the trunk:
svn co http://your/repo/trunk my-trunk
The problem with this is that you don't have the tags or branches directories so literally you can't just go there and create a new tag by copying the trunk. To do so you'd have to check it out first and thus get all the tags and branches.
Luckily there's a little trick to do "partial" checkouts in SVN.
Let's take the example of RIG: I have a bazillion of tags in the repository. Let's do a checkout:
export URL=https://rig-thumbnail.svn.sourceforge.net/svnroot/rig-thumbnail svn co $URL rig-svnThe problem with that is that I get 90 MB of code with 80 MB in
rig-svn/tags alone.
So here's the trick: svn co accepts a -N argument which makes it non-recursive.
This means you can checkout the top directory only and then selectively choose which
sub-directories to include.
So let's try it again:
svn co -N $URL rig-svn # this does not actually checkout any code! cd rig-svn svn up -N tags branches # same we don't get any code here svn up trunk # here we get the real deal
After the fact you end up with this directory structure:
rig-svn/.svn rig-svn/trunk/...(all sub dirs and files here) rig-svn/trunk/.svn rig-svn/tags rig-svn/tags/.svn rig-svn/branches rig-svn/branches/.svn
This means you can work all you want in the trunk and when ready you can create a tag or a branch -- because the corresponding directories are present. And yet you're not wasting 90% of space disk in the process.
Sites:
So overall:
$ svn checkout svn://svn.mplayerhq.hu/ffmpeg/trunk ffmpeg $ svn co svn://svn.videolan.org/x264/trunk x264-trunkand for lame get the latest from the download page on sourceforge:
$ wget http://easynews.dl.sourceforge.net/sourceforge/lame/lame-3.97b3_.tar.gz
cd ../x264-trunk
./configure --enable-vfw --enable-visualize && make && make install
cd lame-3.97 ./configure --enable-nasm make make install
cd ../ffmpeg ./configure --enable-mp3lame --disable-ffserver --disable-ffplay --extra-ldflags="-L/usr/local/lib" make cp ffmpeg.exe /usr/local/bin/.
Previous article: 2005/10/09
This is a very highly summarized overview of how to use Subversion for those of us who are used to CVS. Note that none of this is original, it is all extracted from the Subversion Book, available freely online. I'll link to parts of the HTML online version when relevant.
Note that this does not intent to be generic. Instead, this highlights subversion usages as I need for my own usage patterns. Your mileage may vary. The bottom line is that you're way better off reading the book, especially the quickstart.
So first let's install subversion, that's the easy part:
# apt-get install subversionThat's the only thing needed as root, unless you want the to use webdav or https over Apache, which I don't care for right now. For using subversion over my lan, I used
svnserve.
Now, under whatever user is going to use the repository, we need to create the initial repository itself:
$ svnadmin create /home/user/svnroot
Subversion typically calls the repository repos. However I'm used to having a
cvsroot around so I choose svnroot accordingly.
To serve this over the lan, we'll use svnserver.
There are lots of possible configuration, including inetd and ssh-tunnel based.
The basic command-line manual daemon will work just fine, see the link above for other methods:
$ svnserver -d -r /home/user/svnroot
Now that's all we need for administration, we can start fiddling with projects.
First, we need to understand what Subversion is and is not:
The only things in common between Subversion and CVS are that both do version control and they have similar patterns for basic operations, meaning the words import, add, update and commit are used to mean the same concepts (contrast this with Perforce where one performs syncs and submits.) The words branches and tags however do not mean the same thing. Nor is the repository concept the same.
So let's be blunt: if you want something that is exactly like CVS, then just stay with CVS. However a quick overview of Subversion instantly shows that it's worth spending the time to adjust to some of its own paradigms:
If you want to understand what this really means, I urge you to read the basic concepts and the branching and merging chapters of the book.
In contrast to CVS, the repository is a unique directory that contains all projects merged together. This is not like CVS where each project is its own little repository. The layout of projects inside the subversion repository is left to the user. There is a canonical layout advocated by the book and it can help to mimic those (so that others accessing your repository can recognize the layout immediately.)
The layout goes like this:
svnroot/projectA/trunk/file1.cc svnroot/projectA/trunk/file2.cc svnroot/projectA/branches/somebranch/... svnroot/projectA/branches/anotherbranch/... svnroot/projectA/tags/sometag/... svnroot/projectB/trunk/... svnroot/projectB/branches/onemorebranch/... svnroot/projectB/tags
That is the top-level directories of the repository are the projects, which each
contain trunk (main development line), branches (full copies of the
trunk for branching) and tags (full copies of the trunk for tagging.) It is
important to note that the names used (trunk, branches and tags) are pure
convention, the names themselves are not special to subversion -- we could use
"premium, cheese and pythons" except for the fact the users would be totally lost.
Note than one key difference with CVS here is that all projects are just directories in the same repository and remember that revisions are just snapshots (aka sequence numbers of these snapshots) on the ''full' repository. So committing one file in one project essentially snapshots all projects at once. Although it may sound odd at first, one benefit of this is obvious: if one project is a main software and another one is a a common library used by many other projects, you get automatic synchronization between the main software and all its libraries. This makes it easier to create tags and branches that are consistent, where in CVS you'd have to manually tag or branch each individual project.
Another important difference with CVS is how to deal with branches and tags. Contrary to CVS, subversion doesn't have branches or tags per see at all. All it has is the concept of a repository snapshot at time T and a concept of a shadow copy (a.k.a. copy-on-write) which they call cheap copies in Subversion linguo. So really branches and tags are "full" copies of the repository within itself. So the idea is to have the following convention:
Remember that the "branches" and "tags" directories are pure conventions. So in fact you don't even need to bother creating them until you actually need them. And if you plan to never use branches or tags, there's not even the need to have a "trunk" directory in the first place.
So here's an alternate layout that might work better for me:
svnroot/trunk/projectA/... svnroot/trunk/projectB/... svnroot/stable/sometag/projectA/... svnroot/stable/sometag/projectB/... svnroot/unstable/...
The thing is that I generally don't need branches. However I use tags to mark releases and I have stable releases vs unstable releases.
So let's try this for my repository:
$ mkdir tmpsvn $ mkdir tmpsvn/cs $ cp -r /oldcvs/Project tmpsvn/cs/. $ svn import tmpsvn file:///home/user/svnroot
Note that this will import all the content of tmpsvn, and not the top
directory itself.
Now we can trash the tmpsvn and perform a real checkout.
The thing is that whatever is checkout will be made a directory, just like a CVS
project. So the following svn checkout will only yield workarea/cs/:
$ mkdir workarea $ cd workarea $ svn checkout file:///home/user/svnroot/cs $ ls -la cs
However there's a problem here: the top-level of the checkout doesn't seem to have
a .svn associated with it, so I can't act on it.
Seems like what I want is really to get svnroot:
$ svn checkout file:///home/user/svnroot $ mv svnroot workarea
Note the URL-like argument above. If we want to use a LAN based svnserve
server, we would probably do something like this:
$ svn checkout svn://hostname/path/relative/to/the/svnserve/argument
This gets tedious very fast. Of course once you have a working copy you no
longer need the URL thing (i.e. just svn status, svn commit, etc.) But
still, I miss my old $CVSROOT:
$ export S=svn://hostname/path $ svn checkout $S/cs
Now back to my repository, I just realized I wanted the following layout:
svnroot/<language-name>/<project-name>
So in practice I'll have this:
svnroot/python/Rig2
svnroot/csharp/AppSkeleton
svnroot/csharp/DualTimeZone
svnroot/csharp/LibUtils/LibUtils{2,Test...}
svnroot/tags/...
Language name is going to be a full word (shell, python, ruby, csharp, php.) Oops above I started with "cs" instead of csharp. No biggie:
$ cd workarea $ svn rename cs csharp $ svn commit -m "Renamed cs to csharp"
And let's create a bunch of language directories since I'll need them:
$ svn mkdir python ruby shell php misc cpp $ svn commit -m "Language top-level dirs"
However, once I get a bunch of other languages in my repository, I want to be able to only extract a part of it:
$ cd workarea $ mkdir csharp && cd sharp $ svn checkout file:///home/user/svnroot/csharp -> creates a csharp directory here $ mv csharp svn $ pwd -> workarea/csharp/svn
The good part here is that contrary to CVS I can screw up my layout and directory naming scheme and easily fix it. That means I can safely adopt my own repository layout and go back to the traditional trunk/branches/tags later if necessary. The other good part, as seen above, is that you can checkout just a part of an existing bigger repository and not pull everything at once -- which incidentally can be used to mimic CVS's per-project repository paradigm.
Now I want to import another project, which is already versionned using subversion in googlecode. Currently subversion doesn't allow to copy between existing repositories, so instead I'll check it out and move it manually:
$ cd workarea
$ mkdir python && cd python
$ svn checkout $S/python
$ mv python svn
$ cd svn
$ svn checkout http://rig2.googlecode.com/svn/trunk/ rig2
$ find rig2 -name .svn -exec rm -rfv "{}" \;
$ mkdir tmprig2
$ mv rig2 tmprig2/.
$ svn import tmprig2 $S/python
$ svn update
$ rm -rfv tmprig2
OK it's a bit convoluted but remember how I said these are commands dedicated to my needs.
From man cvs, repeated here because it's incredibly useful and I can never
remember the exact sequence:
Creating the branch after editing
Say you have been working on some extremely experimental software, based on whatever revision you happened to checkout last week. If others in your group would like to work on this software with you, but without disturbing main-line development, you could commit your change to a new branch. Others can then checkout your experimental stuff and utilize the full benefit of cvs conflict resolution. The scenario might look like:
[ hacked sources are present ]] $ cvs tag -b EXPR1 $ cvs update -r EXPR1 $ cvs commit
The update command will make the -r EXPR1 option sticky on all files. Note that your changes to the files will never be removed by the update command. The commit will automatically commit to the correct branch, because the -r is sticky. You could also do like this:
[ hacked sources are present ]] $ cvs tag -b EXPR1 $ cvs commit -r EXPR1
but then, only those files that were changed by you will have the -r EXPR1 sticky flag. If you hack away, and commit without specifying the -r EXPR1 flag, some files may accidentally end up on the main trunk.
To work with you on the experimental change, others would simply do
$ cvs checkout -r EXPR1 whatever_module
Links:
Blog Archives:
Most recent posts
2006/08/07 - 2005/10/23
2005/10/15 - 2004/12/11
2004/12/04 - 2004/03/14
2004/04/07 - 2003/09/18
[RSS]
|
|
This work is licensed by Raphaël Moll under a Creative Commons License.
|
|
| Color Theme: | Gray | Blue | Black | Sand | Khaki | Egg | None |
|
|
|
|