Being able to have common profiles for my Mozilla products across operating systems on my main computer has been a dream for a few years now.
I tried this a few years ago between Slackware and my then secondary OS, Debian (stable). The way I had it set up then worked well until the day that Debian dropped FF and TB from their repos and started using their own IceCritters. Another problem I had back then was that Debian’s Mozilla apps were usually quite a bit older versions than the ones in Slackware. If the versions get too disparate, as they eventually did between Slack and Debian, the common profiles no longer function properly.
Later on, when I adopted Arch Linux as my secondary OS, I tried to run common profiles again. I had forgotten my lesson about needing similar versions of the Mozilla apps for the common profiles to work. Arch is much faster at getting newest versions into their repos than Slackware, so once again I had this version disparity issue. Since Mozilla’s recent change to the update-as-often-as-you-change-underwear schedule, I’ve learned to blacklist Mozila apps in Arch so they don’t get updated. Once Slackware puts out an update (I manualy download and install from current) for the Mozilla applications (Firefox, Thunderbird, Seamonkey), I allow the Arch update to go through.
Now that I have my Slack and Arch Moz versions the same or very similar, the common profiles should work. Below is a look at how I did it on my system. It will, of course, be different on yours, but the principles are about the same.
First, I used a common partition on a separate internal hard drive for my common profiles directory.
This partition automounts within my /home/<user> directory at boot up. You could theoretically use a thumb drive for this, if you wanted to. You’d just have to make sure that it automounts with the proper permissions at boot time.
Next, I copied the firefox and seamonkey directories from my Slackware (main OS) /home/vtel57/.mozilla directory into my newly created /home/vtel57/vtel57_common/common_mozilla directory. I also copied the contents of the .thunderbird directory into a directory called thunderbird also in /home/vtel5/vtel57_common/common_mozilla. You can perform these operations from the command line or in your GUI file manager app, as you prefer.
Now, in the /home/vtel57/.mozilla directory, I renamed the old firefox and seamonkey profiles to inoperative. The old profiles had some random <number/letter>.default as their name. I just added “inop” to the end of that to deactivate them. I did the same with the /home/vtel57/.thunderbird profile. This will prevent the apps from trying to use these old versions.
vtel57_Slackware~/.mozilla/firefox:$ mv 3mvew7qq.default 3mvew7qq.default_inop
Back in the new common directory shown above, I renamed the <number/letter>.default profiles to names that made more sense to me: ff_profile.default, tb_profile.default, and sm_profile.default.
Once I did all of the above, I needed to edit the profile.ini in each original application directory (/home/vtel57/.mozilla/firebird and seamonkey, /home/vtel57/.thunderbird) to point to the newly created common profiles. You can open your favorite gui or command line editor and make these changes to each profile.ini file. Here is my profile.ini for Firefox, for example:
*change the items in red to the ones in green
So now, whenever I fire up firefox, seamonkey, or thunderbird in either Slackware or Arch, they will be running off the same profiles; meaning all data, preferences, etc. are synch’d. Ain’t it great!?
I’m sure there are easier ways to do this, but this is how I managed it. You can experiment to find what works best for you on your systems.
Yes, I’m still on spring hiatus, but the place was getting to look a bit run down.
Plus, I wanted to show you all how to install this cool little browser that I found called Midori. Oh, it’s nothing new. It’s been around for a while, but it’s new to me. I first found it while using Salix OS recently on one of my tester partitions. I’m also using it in Zorin OS on one of my laptops. It’s fast. It’s pretty simplistic and minimal, too.
It is a bit complicated to install on Slackware, though. However, I’m sure you can do it. It just requires using some excellent SlackBuild scripts provided by the dedicated folks at SlackBuilds.org. Unfortunately, Midori is not one of those apps that you can install with just one SlackBuild. It has some dependencies… and its dependencies have some dependencies.
That always complicates things a bit, particularly in Slackware where you have to be smart enough to resolve dependency issues on your own. There is no a gaggle of volunteer repo maintainers doing it for you. That’s alright, though. Slackers are known to be smart and tough. We can take it. Dependency H3LL don’t scare us none. 😉
Let’s get started, OK?
Fire up your current browser and navigate to SlackBuilds.org. You know the place. You’ve been there before. Once you’re there, you’re going to search and download six different SlackBuild scripts and their related source tar balls. Got that? OK.
Here they are (click for the SlackBuilds.org page for each one):
Midori is your ultimate goal. It requires webkitgtk, libunique, and vala. The others are dependencies of webkitgtk and will have to be built first and installed before you build webkitgtk.
You should be familiar with the whole SlackBuild thing by now. Just in case, though, I’ll run through one for you.
Let’s build libunique first:
1. Download the source and the SlackBuild
2. Decompress the SlackBuild (using Xarchiver or your favorite tool)
3. Move the newly untar’d directory to your favorite temporary build directory
4. Move the libunique source package to the untar’d libunique SlackBuild directory (see Fig. 1)
5. Open a terminal and make the script executable:
# chmod +x *Build
6. Execute the script:
# sh *Build
NOTE: If you’re building on a 64 bit Slackware, you should use the prefix Arch=x86_64. For example: # Arch=x86_64 sh *Build
7. Once the script completes, using Slackware’s pkgtool to install the newly created .tgz package you’ll find in your /tmp directory:
# installpkg libunique*
NOTE: You might also want to keep these packages somewhere safe in case you ever want to reinstall Midori on this system or another Slackware installation somewhere.
Now, we need to build and install the rest of the dependencies in this order: icu4c, libsoup, vala. Once you’ve built and installed these guys, you can then build and install webkitgtk. Something to keep in mind once you begin your webkitgtk build; it is NOT one of those zippity-fast builds. Even on a fast system, it may take 45 minutes to build. Just be patient. Don’t sit there waiting for the pot to boil. Go have some dinner or take a healthy walk around the neighborhood while it builds.
OK, assuming you’ve managed to build and install libunique, icu4c, libsoup, vala… and then webkitgtk, you should now be able to build and install midori. It’s a pretty fast build, less than 1/2 a minute. Install it using pkgtool, as you did with the others above. If all went well, you should have a nice working Midori browser on your system now. If you run Xfce4 like I do, it will automagically show up in the Menu –> Network sub-menu.
Here’s my Midori running with the Midori Home Page opened:
NOTE: That’s an April Fools post you’re seeing there about merging Midori with Postler. 😉
Have lots of FUN! 🙂
P.S. I’m going back on hiatus now. See you again soon…
Let me state right out in the open here that my knowledge of computer networking is lacking. I’m learning as I go.
For most of the time that I’ve used computers in my home, I’ve only had one machine going at any given time. This past year or so, though, I’ve gained two more systems in addition to my main system. I have a laptop and a shop system up and running now in my home. The laptop connects via Ethernet or wireless. The shop system, which is outside in my workshop connects via wireless 100% of the time.
The main OS on all three of these systems is Slackware. For a year now, I’ve been running back and forth with thumb drives or CDs filled with data to keep the systems in sync with one another; mostly my personal documents, music, and Mozilla settings. I occasionally use DropBox for small files, but it’s not feasible for larger stuff due to its slow upload speeds. Cloud computing ain’t never going to work as long as ISPs throttle upload speeds.
Anyway, back when I first got the laptop, I attempted to network it with my main system. I failed miserably and ended up throwing in the towel. You can read about that learning experience in this long thread at Scot’s Newsletter Forums – Bruno’s All Things Linux. You’ll see that quite a few folks there were trying to help the dunderhead get his systems linked. Well, I finally succeeded just this past weekend.
Sometimes, you just have to walk away from a problem for a while. 😉
Here’s how I finally got it working using ssh:
- Make sure that the ssh daemon script is executable so that it will run at boot up
#chmod 755 /etc/rc.d/rc.sshd
- Modify the /etc/ssh/ssh_config as follows:
# Port 22
Port <your port choice>
# Protocol 2,1
*Either un-comment and change the default port setting and the protocol or just add a line, as I did.
The purpose of this is mostly for security. Changing the port to a port of your choosing enhances your “security by obscurity” chances. Changing to to Protocol 2 is recommended because there are security flaws in Protocol 1.
- Modify the /etc/ssh/sshd_config as follows:
Port <your port choice>
# The default requires explicit activation of protocol 1
- In your router’s Administration preferences (see your manufacturer’s instructions) you’ll need to set each device you plan on linking via ssh to use a static IP address. This has nothing to do with your ISP’s assigned IP address. This is just your home network we’re talking about here. The router assigns an IP to each device hooked to it. In order to ssh into remote devices, you’ll need to make sure the devices’ IP addresses don’t change (static).
That’s it. You are ssh’ing now, my friends.
It’s easy to access your remote machines now.
$ssh <username>@<device name>
The username is the name of the account that your are trying to access on the remote machine, say your wife Debbie’s account. The device name is the domain name of the device. Like this…
Once you enter the password for Debbie’s account, you’ll have access to her user data and privileges.
In Arch Linux, the process is a bit simpler. First, make sure you have openssh installed on your Arch system. You still need to modify the ssh_config and sshd_config files in a similar fashion, but the getting the daemon to run at boot time is as simple as just adding “ssh” to your /etc/rc.conf file.
You can manipulate (edit, backup, copy, etc.) files on remote machines using ssh from the command line. However, to transfer files between machines, you might want to use ftp. It’s easier, in my opinion. Personally, I use gFTP in Slackware and Arch for this. There are many other choices out there, though. Use whatever works best for you.
So, there you have it. My next project is going to be adding my printer to my router’s USB connection and setting it up as a network printer for all three of my systems.
I’ve been busy designing a website for a client this past week or so.
I just wanted to pop in here real quick-like and tell you about a good article I just read over at Linux Journal. It’s a mini command line tutorial on how to backup CDs to .iso files. You’ll like it.
Learn something. It won’t hurt you none. I promise.
SlackBuilds are custom written installation scripts used to install non-native applications into your Slackware Linux operating system.
For today’s little SlackBuild tutorial, I’m going to use a SlackBuild to install PysolFC, a collection of really cool card games and majong-type games that is maintained by my friend Matthew Fillpot. Matt is one of the lead gurus over at the Linux.com Community site. Stop on over for a visit sometime.
One of the first things I do on any of my Linux installations is to create a hidden directory called .build in my /home directory that I use primarily for manual compiling of applications, or in this case in Slackware, installation of SlackBuild scripts (see Fig 1).
Figure 1 – /home/<user>/.build
OK, let’s get started. The first thing you’ll need to do is navigate to SlackBuilds.org in your favorite browser. In the small search window in the upper right hand corner, type in the application you’re looking for. In this case, that would be PysolFC. Once the search is completed, you’ll be on the pysolfc SlackBuild page (see Fig 2).
Figure 2 – Pysolfc SlackBuild Page
Now, the next thing you’ll need to do is download the source (PySolFC-1.1.tar.bz2) and the SlackBuild (pysolfc.tar.gz) into your .build directory (or wherever you want to build your stuff). Untar the SlackBuild script from the command line using this command:
$ tar -xvf pysolfc.tar.gz
Or you can unpack it using your favorite graphical decompression app like Ark or Xarchiver… use whatever you’re comfortable with.
You’ll now have an uncompressed directory called “pysolfc”. Move the source directory (PySolFC-1.1.tar.bz2) that you downloaded previously into your newly uncompressed pysolfc directory. That’s right. Just grab and drag that source directory right on into the pysolfc directory (see Fig 3).
Figure 3 – Inside the Pysolfc Directory
OK, then… Now for some fun command line stuff. I know you love working in the command line. Don’t be afraid. Just follow my directions. Alrighty…
1. Open your terminal application (Gnome Terminal, Konsole, etc.)
2. Type the following command to make the pysolfc SlackBuild script executable:
$ chmod +x pysolfc.SlackBuild
3. As root (to install globally on your Slackware system so all users can access), type the following command:
4. If all went well, the SlackBuild script will have created a .tgz application installer in your /tmp directory. Navigate to the /tmp directory in the terminal:
# cd /tmp
5. Check to see what’s there:
6. You should see a file called pysolfc-1.1-i486-2_SBo.tgz. That’s the baby! Install it using Slackware’s native pkgtool:
# installpkg pysolfc-1.1-i486-2_SBo.tgz
Voila! That’s it, folks. Easy-peasy. You’ll find an entry for PysolFC in your menu. Click on it and waste a few hours of your life playing some of those funky solitaire card games or that majong stuff.
Have FUN with it…
Note: This article originally appeared on my Nocturnal Slacker/Lockergnome blog (now defunct).
… you can’t have just one.
Multi-booting – My Way
I’ve been multi-booting since I first came to Linux. Originally, it was due to my transition from MS Windows to GNU/Linux. Later, it was because I wanted to try more distributions. I was still hunting for the one that fit me best. I’ve since found that distro (Slackware). However, I still have multiple operating systems on my computer for varying reasons.
My current hard drive partition and usage map looks like this:
SATA 1 – Main/Secondary OS + Linux Archive
Primary – 25Gig: /(root) Slackware on /dev/sda1 (ext3)
Primary – 50Gig: /home Slackware on /dev/sda2 (ext3)
Extended – 175Gig: /dev/sda3
Partition – 25Gig: /(root) Debian on /dev/sda5 (ext3)
Partition – 50Gig: /home Debian on /dev/sda6 (ext3)
Partition – 2Gig: /swap (common) on /dev/sda7 (swap)
Partition – 98Gig: Linux Archive on /dev/sda8 (ext2)
SATA 2 – MS Windows + Experimental Operating Systems
Primary – 25Gig: MS Windows Main on /dev/sdb1 (ntfs)
Primary – 25Gig: MS Windows Programs on /dev/sdb2 (ntfs)
Extended – 200Gig: /dev/sdb3
Partition – 2Gig: /swap (common) on /dev/sdb5 (swap)
Partition – 15Gig: /(root) CentOS on /dev/sdb6 (ext3)
Partition – 25Gig: /home CentOS on /dev/sdb7 (ext3)
Partition – 15Gig: /(root) Arch Linux on /dev/sdb8 (ext3)
Partition – 25Gig: /home Arch Linux on /dev/sdb9 (ext3)
Partition – 15Gig: /(root) PCLOS on /dev/sdb10 (ext3)
Partition – 25Gig: /home PCLOS on /dev/sdb11 (ext3)
Partition – 15Gig: /(root) Sidux on /dev/sdb12 (ext3)
Partition – 25Gig: /home Sidux on /dev/sdb13(ext3)
Partition – 15Gig: /(root) Mandriva on /dev/sdb14 (ext3)
Partition – 23Gig: /home Mandriva on /dev/sdb15 (ext3)
EIDE 1 – Backups
Primary – 50Gig: Slackware Backups on /dev/hda1 (ext2)
Primary – 50Gig: Debian Backups on /dev/hda2 (ext2)
Extended – 150Gig: /dev/hda3
Partition – 50Gig: MS Windows Backups on /dev/hda5 (FAT32)
Partition – 50Gig: Other OS Backups on /dev/hda6 (ext2)
Partition – 50Gig: OS Common Storage on /dev/hda7 (FAT32)
These three drives add up to three quarters of a Terabyte of space… way more than I actually need. However, space is cheap these days. I still remember paying $100 for a 10Gig drive less than ten years ago. Previously, SATA 1 and 2 were in RAID 1 (mirrored) configuration with MS Win XP Pro on them. What a waste. I rarely ever boot that OS these days (games only), so I broke the RAID down and repartitioned/reinstalled everything on my system.
The ten partitions you see on the SATA 2 drive are my experimental Linux slots. When this partition map was made, I intended to put CentOS, Arch, and Ark back on them, with the last two saved for Gentoo and maybe FreeBSD. It didn’t work out quite that way, as you can see. What is installed on those experimental partitions tends to change often.
A few things to take note of when partitioning and multi-booting in this fashion:
1) Remember the SATA 15 partition limit. Many newer distros use the libATA kernel drivers which force drive recognition as SATA regardless of whether the drive is EIDE or SATA, so for this reason remember to place your /common partitions and /swap partitions on the lower numbered ones. A libATA distro installed anywhere else on the lower 15 partitions (or another drive) will still be able to “see” and mount them this way.
2) MS Windows is like the “Borg” when it comes to being installed on a computer with other operating systems. It seeks out and destroys other operating systems. Be sure to install MS Windows first. It needs to be on the first partition of whatever drive you’re installing it on. After which, you can install your GNU/Linux distros safely.
3) Install your MBR controlling distribution last, time-wise, regardless of which partition/drive you’re installing on. This will allow it, especially in the case of Debian’s excellent GRUB, to “see” all the other installations and write them into your menu.lst for you. Even though Slackware is my primary operating system, and since I don’t use LILO, I allow Debian to control the MBR and boot my system with its GRUB.
4) Lastly, as in the case above, if your MS Windows installation is on a different drive than your MBR controlling OS, then your BIOS may have troubles booting the correct drive. No matter what you choose in BIOS as the first device, the Windows drive will boot. The reason for this is that Windows installs a bootable flag on its own drive. This flag gets priority from the BIOS. To set a bootable flag on the drive that you want to boot will require a bit of manipulation using a Live Linux CD* and the fdisk command.
Boot your Live CD and start it. From a terminal session within the CD do the following:
# fdisk /dev/
fdisk> a (option to toggle bootable flag on drive
–partition number? 1 (first partition on the drive)
fdisk> w (command to write the new info to disk and exit fdisk)
–bootable flag reset for this drive
This will set the bootable flag to the drive you choose. Reboot, go into BIOS setup and choose your first boot drive. It should boot fine now.
*Another option to use is the way I actually did it on my own system… I used SLAX on a flash drive to perform the fdisk above. Worked like a champ!
Anyway, that’s the way my system is set up. Whenever I add or change operating systems, I just edit the Debian /boot/grub/menu.lst to reflect those changes.
Have fun with it!
Until next time…
Note: This article first appeared on my Linux.com Community Blog (now defunct). Some of the above is out-dated. I currently only run Slackware (primary), Arch (secondary), CentOS (tester1), and Debian (tester2).
Some of you Slackers out there who use this panel applet may have noticed that it’s no longer updating.
There’s a reason why: Xfce Bugzilla – Bug 8105.
I’d been sloughing this off for a few weeks now. Today, I decided I was going to find a way to fix the damned thing… or dump it from my panel. I had noticed last night that it was still working fine in my Arch installation. Hmm… seems that the Arch folks patched their package with a working license key and partner ID to alleviate the bug issue reported above.
The first thing you want to do is extract the /xfce4-weather-plugin-0.7.4/panel-plugin/weather.h file from the source tarball. Modify this file as per the patch linked above by exchanging the old license key/partner ID for the newer ones:
#define PARTNER_ID “1121946239”
#define LICENSE_KEY “3c4cd39ee5dec84f”
#define PARTNER_ID “1003666583”
#define LICENSE_KEY “4128909340a9b2fc”
Once that’s done, save the file and add it back to the tarball.
Now you can build and install your SlackBuild as you normally would. After which, your xfce4-weather-plugin will work again. YAY! Thanks, Robby! 🙂
NOTE: I found no need to modify the SlackBuild file as Robby does for his patch. It worked fine without any changes.
Enjoy your weather, wherever you may be.