My Exchange Server 2010 installation kept generating errors in the event log that looked like this:
Exception: System.ServiceModel.ServiceActivationException: The service '/Autodiscover/autodiscover.xml' cannot be activated due to an exception during compilation. The exception message is: This collection already contains an address with scheme http. There can be at most one address per scheme in this collection.
Indeed in my IIS installation I have multiple websites that share the same port number. In fact, the default website that hosts the auto discover service supports several different domain names in its header.
After a little googling around, I found a solution here:
http://stackoverflow.com/questions/561823/wcf-error-this-collection-already-contains-an-address-with-scheme-http
Essentially what I needed to do was to open up the "web.config" file in "C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Autodiscover", and add the following lines in the
"system.serviceMode/serviceHostingEnvironment" section:
<baseaddressprefixfilters>
<add prefix="http://programount.com"></add>
</baseaddressprefixfilters>
There were similiar errors for some other Exchange 2010 services, and the same fix worked for those as well.
Saturday, July 7, 2012
Trouble with NAT in Windows 2008 R2 RRAS
IP address and port forwarding in the Network Address Translation (NAT) feature of Windows 2008 R2 Server's Remote and Routing Access Service (RRAS) is surprisingly difficult to setup. Unlike previous versions of Windows Servers that I used before, the graphical user interface for NAT is simply broken in this version.
With previous versions of Windows Servers, I could right click on the public interface under NAT, select "Properties" from the popup menu, go to the "Services and Ports" tab, and then specify how I wanted certain ports to be forwarded to another machine on the LAN. With Windows 2008 R2, however, the settings in on this tab do not seem to work. In fact, other than forwarding to local loop back address of 127.0.0.1, turning on anything here will only break things. Outgoing internet connection sharing works, but incoming port forwarding settings through this GUI are completely useless.
It turns out that you now need to use a command line tool to do this. The mappings cannot seem to be named, but at least you can get port/address forwarding to work (
http://www.rickwargo.com
/2011/01/08/ port-forwarding-port-mapping-on-windows-server-2008-r2/).
The command is
netsh interface portproxy add v4tov4 listenport=<public port> listenaddress=<public address> connectport=<private port> connectaddress=<private address>
This "netsh" command actually does many other things. There is just no GUI for it. For example, you can run the following command to see what port forwarding settings are in place:
netsh interface portproxy show v4tov4
When deleting a particular port from the forwarding list, you need to specify both the port number and the address on the command line:
netsh interface portproxy delete v4tov4 listenport=<public port> listenaddress=<public address>
We came to Windows from DOS, now apparently we are moving backwards.
With previous versions of Windows Servers, I could right click on the public interface under NAT, select "Properties" from the popup menu, go to the "Services and Ports" tab, and then specify how I wanted certain ports to be forwarded to another machine on the LAN. With Windows 2008 R2, however, the settings in on this tab do not seem to work. In fact, other than forwarding to local loop back address of 127.0.0.1, turning on anything here will only break things. Outgoing internet connection sharing works, but incoming port forwarding settings through this GUI are completely useless.
 |
| Do not select anything here |
netsh interface portproxy add v4tov4 listenport=<public port> listenaddress=<public address> connectport=<private port> connectaddress=<private address>
This "netsh" command actually does many other things. There is just no GUI for it. For example, you can run the following command to see what port forwarding settings are in place:
netsh interface portproxy show v4tov4
When deleting a particular port from the forwarding list, you need to specify both the port number and the address on the command line:
netsh interface portproxy delete v4tov4 listenport=<public port> listenaddress=<public address>
We came to Windows from DOS, now apparently we are moving backwards.
Thursday, June 14, 2012
Setting up Git(olite)
Git is a version control system. The creator of Linux created Git (the letter g is supposed to be pronounced as the "g" in the word "get" or "guy") because he hates CVS, and he does not like like SVN, either ( http://en.wikipedia.org/wiki/Git_(software) ).
A lot of people seem to like Git. Probably as many as those who like Linux:-). So since I am developing in Java for a FreeBSD system (Mac OS X server), I figure that I would give Git a try.
Like everything else related to Linux, Git is a little confusing. To start, is the "g" pronouced like "the "g" in "get", or is it like the "g" in "gif"? The answer is always simple when you find out, but it always takes two steps.
Git itself does not offer a server. For a version control system, that is a little unusual. If you know how bad SourceSafe is, you would probably start to wonder: is this going to be as bad as SourceSafe. The answer is no. Actually there are a few Git remote repository applications available, such as Gitolite.
There are several version of Gitolite. The latest version is version 3. To continue the tradition of keeping people confused, the different versions must be installed differently. What I describe here are applicable to version 3. It does not apply to early versions, and it will most likely not applicable to future versions.
To install Gitolite, you must first install Git. This part is surprisingly easy. You go to http://git-scm.com/download/mac, and download a .dmg file. You then open the .dmg file, and then click on the .pkg file inside to complete the installation.
Only if the whole process is that easy.
Of course not. To install Gitolite, you need to create a user account. Gitolite will monoplize this user account to act like a server. You probably want to name this user account with the user name "git" since that is what it will be used for. Ideally you would want to set it up in such a way that it does not accept actual login for OS shell access, but during the setup process, I find it much easier logged in as "git".
Step 1. From the home directory of "git" I ran
git clone git://github.com/sitaramc/gitolite
This actually copies Gitolite into git's home directory under "gitolite". To complete the initalization, you would run
sudo ./gitolite/install -ln /usr/local/bin
This creates a file called ".gitolite.rc", a directory called ".gitolite", and a directory called "repositories". The first two are hidden since they start with "." in their names. A constantly used "gitolite.conf" file is in the hidden directory .gitolite under "conf".
Even though the command used here is called "install", I would say it can only qualify as an initializor, not an installer.
Step 2. Create a repository. Open up .gitolite/conf/gitolite.conf, and add a section for your new repository:
repo MyRepository
RW+ = user1
R = user2
...
Here the user names "user1" and "user2" are not users with system accounts. They are just users that you want to give access to the repository.
At this point you do not actually have a repository yet. The official Gitolite instruction says that you must pull the default "gitolite-admin" repository, change it to "MyRepository", and add it back. It turns out that you can run "gitolite setup" to create the empty repository. It seems to know that this is necessary since "MyRepository" is listed in gitolite.conf, but the directory does not exist under "repositories", or if it is empty if you create it yourself there.
Step 3. Setting up users. Even though you would have listed a bunch of users in the "gitolite.conf" file for your repository, they do not yet have access to the repository. In fact, you would wonder: how would these users login into the server?
It turns out that they all login under the user account "git". To differentiate these different users after they login, each would store a different public key in the .ssh directory of "git". So you can run the following command to create the keys needed for each user of "MyRepository":
ssh-keygen -t rsa
When prompted for a file name, you would enter a user name for "MyRepository". You will then need to distribute the private key file to the user. For example, if the the file name is "user1", you would give it to user1.
After each key pair is created, you would run the "setup" command to update the ".ssh/authorized_keys" file automatically:
gitolite setup -pk .ssh/user1.pub
At this point, user1 can connect to the the repository via ssh.
Step 4. Configure your Git client to access the repository. I use NetBeans. When prompted for user name, you would enter "git" since that is what we used for the user account. So the URL is
ssh://git@myserver.name/MyRepository
You would then enter a file path to the private key generated earlier. This key is what actually tell Gitolite who you really are. If you used a pass phrase while generating the keys, you would enter it here as well.
Step 5. Test your connection. I used PuTTY. The key generated from ssh-keygen needs to be converted with puttygen.exe first before it can be used. The file puttygen.exe is a separate download from PuTTY. Once I connected, I got a bunch of errors. It turned out that the default shell used by Mac OS X server does not have the right paths. So I added a .bashrc file that contained a single line:
export PATH=$PATH:/usr/local/git/bin
This fixed the problem.
A lot of people seem to like Git. Probably as many as those who like Linux:-). So since I am developing in Java for a FreeBSD system (Mac OS X server), I figure that I would give Git a try.
Like everything else related to Linux, Git is a little confusing. To start, is the "g" pronouced like "the "g" in "get", or is it like the "g" in "gif"? The answer is always simple when you find out, but it always takes two steps.
Git itself does not offer a server. For a version control system, that is a little unusual. If you know how bad SourceSafe is, you would probably start to wonder: is this going to be as bad as SourceSafe. The answer is no. Actually there are a few Git remote repository applications available, such as Gitolite.
There are several version of Gitolite. The latest version is version 3. To continue the tradition of keeping people confused, the different versions must be installed differently. What I describe here are applicable to version 3. It does not apply to early versions, and it will most likely not applicable to future versions.
To install Gitolite, you must first install Git. This part is surprisingly easy. You go to http://git-scm.com/download/mac, and download a .dmg file. You then open the .dmg file, and then click on the .pkg file inside to complete the installation.
Only if the whole process is that easy.
Of course not. To install Gitolite, you need to create a user account. Gitolite will monoplize this user account to act like a server. You probably want to name this user account with the user name "git" since that is what it will be used for. Ideally you would want to set it up in such a way that it does not accept actual login for OS shell access, but during the setup process, I find it much easier logged in as "git".
Step 1. From the home directory of "git" I ran
git clone git://github.com/sitaramc/gitolite
This actually copies Gitolite into git's home directory under "gitolite". To complete the initalization, you would run
sudo ./gitolite/install -ln /usr/local/bin
This creates a file called ".gitolite.rc", a directory called ".gitolite", and a directory called "repositories". The first two are hidden since they start with "." in their names. A constantly used "gitolite.conf" file is in the hidden directory .gitolite under "conf".
Even though the command used here is called "install", I would say it can only qualify as an initializor, not an installer.
Step 2. Create a repository. Open up .gitolite/conf/gitolite.conf, and add a section for your new repository:
repo MyRepository
RW+ = user1
R = user2
...
Here the user names "user1" and "user2" are not users with system accounts. They are just users that you want to give access to the repository.
At this point you do not actually have a repository yet. The official Gitolite instruction says that you must pull the default "gitolite-admin" repository, change it to "MyRepository", and add it back. It turns out that you can run "gitolite setup" to create the empty repository. It seems to know that this is necessary since "MyRepository" is listed in gitolite.conf, but the directory does not exist under "repositories", or if it is empty if you create it yourself there.
Step 3. Setting up users. Even though you would have listed a bunch of users in the "gitolite.conf" file for your repository, they do not yet have access to the repository. In fact, you would wonder: how would these users login into the server?
It turns out that they all login under the user account "git". To differentiate these different users after they login, each would store a different public key in the .ssh directory of "git". So you can run the following command to create the keys needed for each user of "MyRepository":
ssh-keygen -t rsa
When prompted for a file name, you would enter a user name for "MyRepository". You will then need to distribute the private key file to the user. For example, if the the file name is "user1", you would give it to user1.
After each key pair is created, you would run the "setup" command to update the ".ssh/authorized_keys" file automatically:
gitolite setup -pk .ssh/user1.pub
At this point, user1 can connect to the the repository via ssh.
Step 4. Configure your Git client to access the repository. I use NetBeans. When prompted for user name, you would enter "git" since that is what we used for the user account. So the URL is
ssh://git@myserver.name/MyRepository
You would then enter a file path to the private key generated earlier. This key is what actually tell Gitolite who you really are. If you used a pass phrase while generating the keys, you would enter it here as well.
Step 5. Test your connection. I used PuTTY. The key generated from ssh-keygen needs to be converted with puttygen.exe first before it can be used. The file puttygen.exe is a separate download from PuTTY. Once I connected, I got a bunch of errors. It turned out that the default shell used by Mac OS X server does not have the right paths. So I added a .bashrc file that contained a single line:
export PATH=$PATH:/usr/local/git/bin
This fixed the problem.
Monday, February 20, 2012
Gotcha’s in gSOAP Version 2.8.7
Nowadays it appears that few people are using C/C++ to do network programming. Microsoft has deprecated its SOAP toolkit. gSOAP of Genivia Inc. seems to be the only way to create C/C++ code from WSDL. Unfortunately, the C++ code that gSOAP generates has a lot of problems. But no one seems to care. I googled for solutions to some of these problems, but I found nothing.
1. The header file generated by wsdl2h can have syntax errors. For example, the class definition of a common class like xsd__base64Binary looks like this:
/// Built-in type "xs:base64Binary".
class xsd__base64Binary unsigned char *__ptr; int __size;
The curly brackets are missing. It turns out that the configuration file had it listed that way. wsdl2h does not care about that, and spits it out without complaints. The same thing happens to an enum definition:
/// Built-in type "xs:boolean".
enum xsd__boolean false_, true_ ;
The name of the enum type is then later used as a class name.
Obviously the code will not even build.
2. The C++ file generated by soapcpp2 incorrect merges two WSDLs into one.
Fortunately wsdl2h allows more than one WSDL. It is a rather common situation that one would need to access more than one SOAP service, and being able to generate code from multiple WSDL’s is quite critical.
But then soapcpp2 would merge them all into one. If you have ServiceA and ServiceB, you will get only ServiceA, with the members of ServiceB actually contained in ServiceA. The default endpoint URL is a concatination of the two service URLs in one:
endpoint = "http://serviceA http://serviceB";
Of course, calling the methods in these proxy classes would be problematic.
Although some of the big name companies like IBM are using gSOAP, but I don’t know how they can be using it as is, unless they are all coding in plain C, not C++.
So we have to go either all the way to a managed language such as Java or C#, or we have to stay with plain old C.
1. The header file generated by wsdl2h can have syntax errors. For example, the class definition of a common class like xsd__base64Binary looks like this:
/// Built-in type "xs:base64Binary".
class xsd__base64Binary unsigned char *__ptr; int __size;
The curly brackets are missing. It turns out that the configuration file had it listed that way. wsdl2h does not care about that, and spits it out without complaints. The same thing happens to an enum definition:
/// Built-in type "xs:boolean".
enum xsd__boolean false_, true_ ;
The name of the enum type is then later used as a class name.
Obviously the code will not even build.
2. The C++ file generated by soapcpp2 incorrect merges two WSDLs into one.
Fortunately wsdl2h allows more than one WSDL. It is a rather common situation that one would need to access more than one SOAP service, and being able to generate code from multiple WSDL’s is quite critical.
But then soapcpp2 would merge them all into one. If you have ServiceA and ServiceB, you will get only ServiceA, with the members of ServiceB actually contained in ServiceA. The default endpoint URL is a concatination of the two service URLs in one:
endpoint = "http://serviceA http://serviceB";
Of course, calling the methods in these proxy classes would be problematic.
Although some of the big name companies like IBM are using gSOAP, but I don’t know how they can be using it as is, unless they are all coding in plain C, not C++.
So we have to go either all the way to a managed language such as Java or C#, or we have to stay with plain old C.
Friday, January 20, 2012
Updating to CentOS 5.7 on a HP Proliant DL380 G5 Server–The Saga Continues
Recently we updated our CentOS server from version 5.5 to 5.7. Many updates were accumulated since the original installation, so I decided to bite the bullet and install them all.
The installation of the updates were straightforward. I did it from the desktop of the GUI, and everything installed without any problems.
But restarting the server was not so straight forward. Since we installed HP PSP, and it was tweaked to work with CentOS 5.5, I certainly did not expect it to work so easily.
Sure enough, the server would reboot itself when it tried to load the IPMI driver.
So at the startup of Linux, I hit the “I” key to go into interactive start up mode. I skipped all of the HP drivers, and the server booted all the way up.
Then I uninstalled all of the HP PSP packages. I downloaded the latest version 8.7 HP PSP and installed it. HP has moved the installation instruction, so the link in my previous post no longer works. Now you can find the same instructions here:
The new version of PSP actually works better than the older one: it works right after installation. No tweaking was required.
There is one thing, however: SNMP had to be re-configured. Before re-configuring SNMP, the management webpage on port 2381 showed a bunch of blank rectangles.
I checked the messages log in /var/log. It showed a couple of bogus errors:
- The “Network Manager” does recognize bonded network adapter type, and logs errors in the messages log. So I removed “TYPE=BOND” from the /etc/sysconfig/network-scripts/ifcfg-bond0. This line was inserted by the CentOS Network Manager GUI, and its absence has no effect on the adapter.
- The slave adapters of the bonded adapter, namely eth0 and eth1, had configurations that caused the “Network Manager” to log errors in the messages log. Although the slave adapters do not have IP addresses, the “Network Manager” looks for them in the configuration files anyway. Somehow it grabbed the MAC address lines and thought that they were the IP addresses. Since the MAC addresses start with “0”, the “Network Manager” logged errors saying that “IP addresses cannot start with 0”. Again since the CentOS Network Manager GUI put the MAC addresses in the configuration itself, I tried to remove them to see if the errors would go away. Well they did not. The “Network Manager” complained that “IP addresses were missing”, even though none are needed for the slave adapters. So I put the MAC addresses back and then set DHCP to be “on” for these slave adapters. These adapters will never go out and acquire IP addresses since they are inactive, but this made the “Network Manager” stop logging errors in the messages log.
On the “System Management Homepage” on port 2381, I wanted to test SNMP traps. Unfortunately the test does actually simulate any hardware trap that the HP SNMP Agents would take notice. Even though in /opt/hp/hp-snmp-agents/cma.conf we setup the trapmail line to send emails, none was sent when I clicked on the test button. Only when I unplugged one of the two network cables that generated traps that the HP SNMP Agent would take notice, I got 60 emails in a fraction of a second.
So the test button on the “System Management Homepage” SNMP settings page only tests notification mechanisms that are not really relevant to the HP SNMP Agents. In order to see the trap messages for this test, one needs to run “snmptrapd –f –Le <hostname>” on the command line, and watch the output on the screen. Please note that in the /etc/snmp directory, there needs to be a file named “snmptrapd.conf”, and it needs to contain the line “disableAuthorization yes”. Otherwise “snmptrapd” would not show anything. The “<hostname>” part must match exactly what is in the “snmpd.conf” file. Using IP address or other aliases will not work.
The HP SNMP monitoring is not very reliable. From time to time the “System Management Homepage” on port 2381 would show a bunch of empty box and indicate the system status is ok. After a reboot, all the boxes will be populated again and everything would go back to normal.
It looks like that we just need to watch this server very closely.
Wednesday, September 28, 2011
Changing the Z-Index of a jQuery UI Selectmenu
I am using jquery.ui.selectmenu on a website that I am building. One of the select controls on a page needs to have its z-index set higher because it is directly above another control that has a non-zero z-index.
The way that jquery.ui.selectmenu is designed is intended to make things really simple: You set the z-index of the original select control, and the rendered select will have the right z-index.
Well it is not quite that simple. jquery.ui.selectmenu uses jQuery’s zIndex() function to get the original select control’s z-index. This function only returns a non-zero z-index if the original select control uses relative or absolute position.
When my select control kept using z-index of 0, I first tried setting it on the ui-selectedmenu, etc. Of course, none worked. So I had to go into the javascript of jquery.ui.selectmenu to see why it was not working, and that was what I found.
So I changed the original select control to uses relative position, and then everything works fine.
Saturday, September 24, 2011
Windows Updates KB2468871 and KB2533523 Keep Reinstalling
On one of my workstations, Windows 7 kept re-installing two updates, KB2468871 and KB2533523, even though the installations were successful each time.
KB2468871 is titled "Update for Microsoft .NET Framework 4.0 on Windows...". More details on this update can be found here.
KB2533523 has the same title, and more details on this update can also be found at Microsoft's website.
Some folks on the internet suggested downloading the update packages and installing them manually. So I did that. It did not help. Some suggested that the update should be done in safe mode. That did not work.
It turned out that for me, the cause of the problem was that I had a .NET 4 beta component installed, and I forgot to remove it. I saw it when I decided I was going to reinstall .NET 4. So I removed it. Now these updates are no longer trying to re-install themselves, finally.
KB2468871 is titled "Update for Microsoft .NET Framework 4.0 on Windows...". More details on this update can be found here.
KB2533523 has the same title, and more details on this update can also be found at Microsoft's website.
Some folks on the internet suggested downloading the update packages and installing them manually. So I did that. It did not help. Some suggested that the update should be done in safe mode. That did not work.
It turned out that for me, the cause of the problem was that I had a .NET 4 beta component installed, and I forgot to remove it. I saw it when I decided I was going to reinstall .NET 4. So I removed it. Now these updates are no longer trying to re-install themselves, finally.
Subscribe to:
Posts (Atom)