As my previous post says, I went live with a new website on Friday. Well, within minutes of going live I realized we didn't have an alias set up for www.myNewSite.com and got my client's administrator to add it. Once it was made live, the alias still didn't work. I had it configured in my tomcat server.xml file, but no dice. What was going on?
When I installed tomcat, I got rid of all the default sites it comes with (and I thought I had gotten rid of all their configs as well. It turned out I hadn't. In the server.xml file the host was configured correctly, but the 'engine' configuration was still pointing to 'localhost' which wasn't in my host configuration anymore. So I pointed it to my new 'root' configuration for the server - so now it looks something like this:
Engine name="Catalina" defaultHost="www.myNewSite.com"
and the host lookes like this:
Host name="www.myNewSite.com" appBase="webapps"
unpackWARs="true" autoDeploy="true"
xmlValidation="false" xmlNamespaceAware="false"
alias myNewSite.com alias
Sunday, May 24, 2009
MySQL service restart, InfoGlue
I have MySQL running behind Infoglue for a new web app one of my clients has. We went into production on Friday with that web site. Saturday evening the hosting providing had a scheduled update and so all the boxes got rebooted. Unfortunately, the MySQL service which was configured to autorestart didn't come back up. In the application event logs (I've got it running on a Windows server) it said:
...MySQL Server 5.1\bin\mysqld: unknown option '--enable-pstack'
I searched the MySQL forums and Google for this error and nothing. I reinstalled the service a couple of times.. and nothing - same error. I was sweating by this time.
Then I started looking at the my.ini file for Mysql in the installation folder (sibling of the bin folder). I saw these lines at the very bottom:
#Print a symbolic stack trace on failure.
enable-pstack
Ah ha. So here's where that 'unknown option' was coming from. I had no idea what was making a failure happen on startup to make it print out this 'stack trace' so I just commented out that line. ...And low and behold, MySQL started up happily and things worked.
Whew.
...MySQL Server 5.1\bin\mysqld: unknown option '--enable-pstack'
I searched the MySQL forums and Google for this error and nothing. I reinstalled the service a couple of times.. and nothing - same error. I was sweating by this time.
Then I started looking at the my.ini file for Mysql in the installation folder (sibling of the bin folder). I saw these lines at the very bottom:
#Print a symbolic stack trace on failure.
enable-pstack
Ah ha. So here's where that 'unknown option' was coming from. I had no idea what was making a failure happen on startup to make it print out this 'stack trace' so I just commented out that line. ...And low and behold, MySQL started up happily and things worked.
Whew.
Friday, May 15, 2009
Custom header in Cruise Control
We have multiple CruiseControl (CCNET) instances running on our build boxes and we've been wondering how to differentiate which one is which so people can know at a glance which one they are pointing at.
This turns out to be relatively easy. In a typical CCNET installation, there's a \cruiseinstalldir\webdashboard\templates directory. Inside it you'll find a file called TopMenu.vm. Open the file up and after the last '#end' put some literal spaces in and type the title of your CCNET site with some plain html formatting to make it obvious (make the font bigger and bold, for example)
...save it and refresh your dashboard page.
This turns out to be relatively easy. In a typical CCNET installation, there's a \cruiseinstalldir\webdashboard\templates directory. Inside it you'll find a file called TopMenu.vm. Open the file up and after the last '#end' put some literal spaces in and type the title of your CCNET site with some plain html formatting to make it obvious (make the font bigger and bold, for example)
...save it and refresh your dashboard page.
Windows and Automated builds
We've run into a couple of interesting situations with Windows with our automated build scripts that I wanted to document. Both of them have to do with inconsistencies with what the Windows GUI is saying about a configuration versus what the operating system is actually using for a configuration.
Both of these situations were discovered while we were trying to do an expansive upgrade of our code to use the new .NET framework. In the first instance we were manually trying to install/uninstall dll's from the gac on a particular box. We manually dragged and dropped a particular dll into the c:\windows\assembly folder and the GUI would say everything was successful with registering the dll in the gac. However, check it from the command line, or try to run something in the application against the newly gac'ed dll and the OS didn't seem to see it. The only way we could get the OS to successfully see the change was to gac the dll from the command line.
In the other instance (which is sort of similar in nature), our automated deploy scripts are creating a Virtual Directory underneath an IIS web site on a remote server. After the Vdir is created, we had a 'step' that automatically updated the ASP.NET version on the Virtual Directory fo 2.0.50727 (C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis -s W3SVC/%WEB_SITE_NUMBER%/Root/%WebSiteName%). This script ran successfully, and the ASP.NET tab in the VDir on the web site displayed the change. However, IIS didn't actually see the change and continued to run the web site on the old 1 .1.4322 version - even though the GUI in IIS said it was. We knew this because the C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files folder didn't have the new corresponding virtual directory folder (this is where IIS keeps the compiled pages - it's like the 'working' folder in Tomcat). It seems the IIS metabase was updated, but the registry was not. I have a hunch that this might be because during that particular deploy, we left IIS running while we did the deploy. Perhaps shutting it down would make the update work properly through to the registry.
Both of these situations were discovered while we were trying to do an expansive upgrade of our code to use the new .NET framework. In the first instance we were manually trying to install/uninstall dll's from the gac on a particular box. We manually dragged and dropped a particular dll into the c:\windows\assembly folder and the GUI would say everything was successful with registering the dll in the gac. However, check it from the command line, or try to run something in the application against the newly gac'ed dll and the OS didn't seem to see it. The only way we could get the OS to successfully see the change was to gac the dll from the command line.
In the other instance (which is sort of similar in nature), our automated deploy scripts are creating a Virtual Directory underneath an IIS web site on a remote server. After the Vdir is created, we had a 'step' that automatically updated the ASP.NET version on the Virtual Directory fo 2.0.50727 (C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis -s W3SVC/%WEB_SITE_NUMBER%/Root/%WebSiteName%). This script ran successfully, and the ASP.NET tab in the VDir on the web site displayed the change. However, IIS didn't actually see the change and continued to run the web site on the old 1 .1.4322 version - even though the GUI in IIS said it was. We knew this because the C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files folder didn't have the new corresponding virtual directory folder (this is where IIS keeps the compiled pages - it's like the 'working' folder in Tomcat). It seems the IIS metabase was updated, but the registry was not. I have a hunch that this might be because during that particular deploy, we left IIS running while we did the deploy. Perhaps shutting it down would make the update work properly through to the registry.
Tuesday, May 12, 2009
Don't assume anything
We are doing a big upgrade of our components in our upcoming release. The security structure of our organization is fairly complex with users, roles, user groups assigned to roles, boxes in the domain, boxes outside of the domain, and a whole other layer of users and roles at the database level. Managing security for this release has been a hassle. It seems in every environment there are differences with who is assigned to what group, which users and which groups have 'these' permissions on 'this' folder, etc.
Thinking we had most of the issues documented, automated and swept under the rug, we deployed into our staging environment. Surprise, surprise, there were permissions issues there. The really interesting thing was these turned out to be new issues. Well, we spend the good part of the day trying to see if we missed a permission on a folder somewhere. In the end, it turned out that our architecture group (who is responsible for the shared components code and the overall enterprise architecture) had some code for applying special permissions that was hard-coded to be applied against ONLY our staging and production environments.
Shock.
I guess it goes to show, don't assume anything - no matter who is responsible for code or where the error seems to be, or how stable you think your configuration are.... We also discovered that that particular componenet had a different security setting for the COM+ in the Staging env compared to the Testing env.
Thinking we had most of the issues documented, automated and swept under the rug, we deployed into our staging environment. Surprise, surprise, there were permissions issues there. The really interesting thing was these turned out to be new issues. Well, we spend the good part of the day trying to see if we missed a permission on a folder somewhere. In the end, it turned out that our architecture group (who is responsible for the shared components code and the overall enterprise architecture) had some code for applying special permissions that was hard-coded to be applied against ONLY our staging and production environments.
Shock.
I guess it goes to show, don't assume anything - no matter who is responsible for code or where the error seems to be, or how stable you think your configuration are.... We also discovered that that particular componenet had a different security setting for the COM+ in the Staging env compared to the Testing env.
Thursday, May 7, 2009
InfoGlue installation
I've been doing a lot of work with InfoGlue lately. I downloaded the new 2.9.6.X release and went to install it and got a 49.0 version error. It seems that the new version of InfoGlue doesn't run as good on Java 1.5 as it's documented to. It worked when I finally upgraded to 1.6. I also had issues getting it to work with MySql because my install of MySql was done with a production box in mind. It seems that the MySql configuration engine clamps down on security when you specify this, and as a result, I had to allow temporary access for root to all schematas, and then have to specify permissions for each user by schemata. While I'm very impressed and happy about this, it made for a little more grief than I was expecting in the installation process.
Also in the InfoGlue installation process, you do want to change the first username/password it asks you for to be the specific one that InfoGlue will use to call the DB with. Not realizing that, I had to go through all my web contexts and change the references to those properties.
Also, deleting a repo in InfoGlue using it's 'force' feature is not a great idea. Better to rename it instead. Sigh. I had to go through and insert data back into a couple of tables to get the repo working properly again.
Also in the InfoGlue installation process, you do want to change the first username/password it asks you for to be the specific one that InfoGlue will use to call the DB with. Not realizing that, I had to go through all my web contexts and change the references to those properties.
Also, deleting a repo in InfoGlue using it's 'force' feature is not a great idea. Better to rename it instead. Sigh. I had to go through and insert data back into a couple of tables to get the repo working properly again.
Subscribe to:
Posts (Atom)