Archive for November, 2005

Microsoft Exchange, data replication

Sunday, November 27th, 2005

Here’s a little issue. If you were to replicate MS Exchange DB from one machine to another, how/what would you have done?

The scenario goes as follows: You have your own domain, and you use, for your own core services AD and MS Exchange for the whole organization. While AD supports some built-in replication, so you could hold a second
site and join a Windows server machine into this domain, and assuming you have some sort of link, you would have a replica of your AD on the secondary site. In case something happened to your primary site, your secondary site would have a complete and correct replica of your primary site.

Exchange doesn’t act that nice. Replicating MS Exchange is not simple, even assuming you have a method of transferring the data from one site to the other.

Two methods I can think of – The first would be to somehow proxy the information getting into it, and transport it (maybe rewrite the headers to point to a different recipient) to another site as well. In this case, you are actually agnostic to the store. You don’t care if you maintain your mailboxes on MS Exchange, Windows, Unix, or whatever system. You have two copies, and you’re fine with it. You should find some logical method to make your primary site’s mail server transport all mail, even internal mail, through this proxy mechanism.

The second method is a bit more interesting. If we could have had a real-time replica of the primary site’s Exchange DB, we would have been able to “mount” it on the secondary site. It is not trivial, but it can be done using some
not-so-common software or hardware based solutions. However, the secondary site would require few things, per this list:

1) Similarity:

I would strive to similarity between both sites. MS recommend similarity (when dealing with cold-recover), per this site, especially with the Exchange patch level, and somewhat with Windows patch level. The more similar, the better chances we’ll have. So:

a. Similarity in patch level.

b. Similarity in Storage group settings, especially transaction logs’ location.

c. Similarity in the structure of each store under each storage group

d. Similarity in the absolute path of each store’s edb and stm location between source and target

2) Recoverability:

To make things recoverable, you should make sure each store has, under the “Database” tab, under properties, the option which will allow restore to overwrite the DB.

3) Flexibility:

You need to find some flexible script which will be able to change, as fast as possible, the pointers in your AD, to point to the new Exchange server, in the users’ Exchange attributes. I have such a script, but I cannot disclose it here.

Armed with these three, you can copy, transfer, replicate, or whatever, your DBs from one location to the other. Make sure you replicate the logs as well, else it’ll get messy, and will require tons of time for DB recovery.

To recover, you should only mount the stores. Assuming you have followed the prerequisites, you would be able to mount the stores in no time. Otherwise, you would need to run eseutil on the stores. It might get messy.

Afterwards, only one thing to do – mass change the attributes of the users in question to point to the alternate Exchange server, and the alternate Exchange store. Should work like a charm.

Security on the net

Sunday, November 20th, 2005

I am not a security expert. I know my way, and I can use common sense, which is the best practice for a good security, but I get to hear terrible things. Not only the hunt for file sharing people is on full throttle, but media companies try (and succeed) in providing yet better, meaner, and more efficient methods of spying on people and preventing them doing any illegal (copy?) procedure, and God knows what more.

This entry is not a technical one, in general, it’s just a bunch of two links (so much for a bunch) I’ve picked on a blog owned by a friend of mine.

So, the first Link, in Hebrew, is this. It forwards directly to the blog in question.

The second, derived from the first one, is about Sony’s last known actions. It can be found here.

Let’s hope we don’t get much more of this. I’m skeptic, but that’s me…

L2TP and Cables in Israel, fixups

Friday, November 18th, 2005

When I’ve created my setup (displayed below), I took into account the possibility of disconnection, or process fall, and I’ve left pppd to deal with it, by trying to connect just as it has fallen down. It was a good solution for the scenarios where there is a temporary, short timed disconnection. It fails to work when pppd cannot establish a connection as soon as it has dropped, which might happen when the ISP has a problem, or someone disconnects the cables, etc.

To try and approach it using an add-on solution (as I don’t feel I have a complete and simple enough solution for the issue), I have added the following things:

1. Added a line in /etc/crontab , adding a per-minute scheduled class:

0-59/1 * * * * root run-parts /etc/cron.minute

2. Created a directory /etc/cron.minute

3. Added a script into it, called Internet, as follows:

#!/bin/sh
if [ ! "`ifconfig | grep ppp0`" ]; then
/etc/init.d/rp-l2tp start
fi

The solution brings back the connection in the rather rare event of it being down. It will not solve, even combined with the current "bring it up when it goes down" configuration all and every possible problem. I hope it would solve enough. I will not list my expected problems with such a configuration, but leave it as an exercise for you.

I’ve been busy, so it’s a long one.

Thursday, November 17th, 2005

It has been long time since I’ve written here before. I got lazy, but I have few new things to share with whoever reads this blog, and myself, for future reference.

First – I’ve got a nice VGA card from a friend of mine, a nice looking TI8200 x8, which is a great upgrade comparing to my older GeForce2 GTS… I’ve put it into my computer, during a major reorganization of our room, and I was unable to boot into X. Not only this, but my computer got hang every time I tried. I’ve tried running X standalone, running it through GDM, XDM, whatever. It got hang as soon as it started. Well, I’ve said to myself, maybe it’s time to upgrade kernel, and recompile this whole NVidia package from scratch. That’s exactly what I’ve done. Using the generic NV driver worked ok. Not good enough, but we can live with it.

I’ve downloaded and compiled 2.6.14.2, configuration attached (config-2.6.14.2), but I was unable to boot into it. It gave me kernel panic just as it should have accessed its initrd (INITial RamDisk). It’s not the first time for me to compile a kernel, so I got confused, until I’ve figured that the method of creating initrd has changed, and now it uses cramfs, while in the past it has used ext2fs. I have altered my /etc/mkinitrd/mkinitrd.conf file (mkinitrd.conf attached), and was able, finally, to boot into my newly compiled kernel. I have installed NVidia’s driver, and things, after a short while, seemed to be ok. For now.

About a year and a half ago, a friend of mine left to Australia, as part of his emigration procedure, there. Few days prior to him leaving us, his wife’s somehow-obtained LCD screen, 17" (at that time it was huge!) broke. It was a nice LCD CTX 17", and it died. We cut a deal so he would get some RAM he needed, and I’ll get the screen as soon as I would pay for repairing it. Nice deal. The screen did not get fixed. It was claims and excuses, and explanations all the time, but the screen has not been fixed. I must admit I have almost completely forgotten about it. All until three days ago, when the electrician called me and told me that the screen is fixed. I could hardly believe it. I’ve came to take it, and it did work, supplying image much inferior to today’s LCD screens, but it worked. I have convinced my wife to use it for now (it’s good enough, and it would supply her with "natural"-like display, looking like her customer’s screens), and I’ve added myself the 2nd one here.

It took me a while to make it work. The generic driver NV failed to use two screens, and the propriety driver, "nvidia" managed to hang my computer once a while.

With the help of this site, I have managed to rebuild, almost from scratch, my xorg.conf file (xorg.conf attached). I have managed to activate dual-head, as displayed in the following pictures:

I have also added a nice card reader to my Linux, and had no hardships with it whatsoever. I’ve added few lines to my /etc/fstab, and they look like this:

/dev/sda /mnt/DoK auto noauto,user,exec,iocharset=utf8,codepage=852 0 0
/dev/sda1 /mnt/DoK1 auto noauto,user,exec,iocharset=utf8,codepage=852 0 0
/dev/sdb /mnt/sdb auto noauto,user,exec 0 0
/dev/sdb1 /mnt/sdb1 auto noauto,user,exec 0 0
/dev/sdc /mnt/sdc auto noauto,user,exec 0 0
/dev/sdc1 /mnt/sdc1 auto noauto,user,exec 0 0
/dev/sdd /mnt/sdd auto noauto,user,exec 0 0
/dev/sdd1 /mnt/sdd1 auto noauto,user,exec 0 0

Here’s a picture of this little thingie.

Mind you that I’ve added Hebrew support only to the first two devices. I’m lazy, right?

Cables in Israel and L2TP on Fedora Core 3 Linux

Monday, November 7th, 2005

I have noticed there is no fixed guide for L2TP for cable connection in Israel. Since I’ve been doing just this thing today, I’ve decided to put online my own comments on the issue, with hope it would help other people too.

Subject: L2TP cables connection to an ISP called Actcom in Israel, using Fedora Core 3

Requirements: FC3 does not come with any L2TP tools and/or configuration packages.

Solution, strongly based upon this site

*) Download and install l2tp packages for FC2/3 from this site. Note that you have to download the rp-l2tp package.

*) Save, with run permissions, the fixroute.txt fixroute script. This script is required so you would have your routing table set correctly. Note, it is a txt file, but a script in the same time.

*) Save this following conf file in your /etc/l2tp as /etc/l2tp/l2tp.conf l2tp.conf.txt

*) Save this following rp-l2tp.txt startup script in /etc/init.d/ as /etc/init.d/rp-l2tp . Note – this script understands the command “chkconfig” . Also note that, as said inside this script, this script assumes l2tpd is running.

*) Make sure l2tpd is running! Add a line such as
lt:3:respawn:/usr/sbin/l2tpd -f

to your /etc/inittab file. It will make sure this daemon will always be resurracted.

*) To set automatic reconnection, replace your /etc/ppp/ip-down script with the following script ip-down.txt

*) Make sure (one of?) your network interface is connected correctly to the Cables modem, that there’s link, and that the interface is defined to use DHCP.

*) Set your /etc/ppp/pap-secrets with something which looks like this:

“username” * “password”

*) Add to /etc/ppp/options the lines:

lock
defaultroute
lcp-echo-failure 2
lcp-echo-interval 30

*) Run init q to reload /etc/inittab, and force the loading of l2tpd.

*) Run /etc/init.d/rp-l2tp start to start the internet connection. With luck, you should be up and running. Add this script to the startup sequence by running “chkconfig –level 35 rp-l2tp on

Done and done. Good luck.