Peter's questions

I recently built an Ubuntu virtual machine for MarkLogic development. The machine was then distributed to 4 other developers to provide a consistent dev platform. Now I'm setting up another piece to the dev puzzle that consists of some java libraries and a JSP web application. The project source lives in the developer user home directory (each machine has the same exact account). I added a symbolic link into the /var/lib/tomcat6/webapps/ directory that points to the web application source root in the project directory.

/var/lib/tomcat6/webapps/jspapp -> /home/developer/dev/workspace/svn/Project/webapp/

(The actual JSP files live in the Project/webapp directory.)

This works fine on my instance of the VM. I successfully replicated the setup to one other VM and it worked fine. However, the rest of the VMs on which I replicate the setup don't work. On the first 2 VMs, I get the web app's pages. On the other VMs I get 404s.

The VMs were all cloned from a single original. All of the web app project source is the same except for 1 configuration value (the local machine's IP address). I created the symbolic link in the same way on each and verified that permissions/modes of the files and directories are the same. I compared the tomcat installation directories and see no configuration differences between them. The only file differences I do see are what appear to be the cache data of Catalina. For all intents and purposes, the setups are identical. Yet, clearly, something is not the same.

Does anyone have a suggestion as to how I can troubleshoot this problem? I am rather new to the linux world and brand new to tomcat.

Update - I copied the contents of the linked directory into a real directory of the same name (after deleting the link) and it still doesn't work. However, I can see a copy of /var/lib/tomcat6/webapps/ROOT/index.html that I put into the directory in question. It's behaving almost like the JSP files are getting ignored.

I'm setting up an automated process on one Windows machine that backs up data from another. The process will run as a local account that exists on both machines and matches user name and password. I'm using the ability of windows to use matching accounts to provide login-less "authentication" which I have used numerous time without issue. However, now I'm encountering problems.

The following two machines are involved:

• DEV03
  • Windows Server 2008 R2 x64 (happens to be a VMware VM, not that it should matter)
  • IP: 10.12.48.97, 10.12.48.88
• DEV04
  • Windows Server 2003 x86
  • IP: 10.12.48.126

Neither of these machines are in an Active Directory domain nor can I place them in one. They are both, however, in the same workgroup.

An account with user name administrator exists on both machines with the same password. The account is in the local Administrators group on each machine.

I RDP into both machines and log in using the administrator account. I then start a regular command prompt from the start menu one of two ways:

• started regularly, running as the desktop session's logged in user (administrator). This is noted in the below results as (logon)
• started with "Run as different user" (2008) or "Run as..." (2003). I still use the administrator account, entered manually. (I realize this seems odd and shouldn't matter, but I included it to be sure I wasn't going crazy and because I'm sure I got different results, but maybe not now that I retest and lay it all out.) This is noted in the results as the account name, administrator

Once in the command prompt I issue a simple dir command on an administrative share on the other machine.

Here's the test result breakdown:

Test RDP ON  Run As          Dir of              Result
=================================================================
1    DEV03   (logon)        \\10.12.48.126\c$  Succeeds
2    DEV03   administrator  \\10.12.48.126\c$  Succeeds
3    DEV03   (logon)        \\DEV04\c$         'Access is denied.'
4    DEV03   administrator  \\DEV04\c$         'Access is denied.'
-----------------------------------------------------------------
5    DEV04   (logon)        \\10.12.48.88\c$   Succeeds
6    DEV04   administrator  \\10.12.48.88\c$   Succeeds
7    DEV04   (logon)        \\10.12.48.97\c$   'Logon failure: unknown user name or bad password.'
8    DEV04   administrator  \\10.12.48.97\c$   'Logon failure: unknown user name or bad password.'
9    DEV04   (logon)        \\DEV03\c$         Succeeds
10   DEV04   administrator  \\DEV03\c$         Succeeds

Pinging DEV03 from DEV04 returns the .88 IP. So I am beginning to think this problem has something to do with the host name. However, I have never encountered this problem before, despite having servers with multiple IP addresses, which makes me suspect Window Server 2008 a little.

I have rebooted both servers and flushed DNS for good measure.

I'm mostly concerned with tests 5 thru 8. Why would the connections behave differently based on the inbound IP address? I don't see anything in IP settings on the server that suggest some difference in authentication behavior. Certainly it's not a firewall issue because it's connecting, just failing authentication.

Are user accounts associated to a windows server host name? Is it possible that the server is associating the host name with the first IP (.88) (event though that was added second) and not recognizing it for the other IP?

I'm in the process of upgrading a pair of physical servers to 3 virtual machines. The 2 physical boxes (HP DL380 G5 with Smart Array P400 disk controller) will run VMware ESXi 4 update 1. Each physical machine has 8 72GB drives originally configured as follows:

• Disk 1 and 2, RAID 1 (mirror), operating system
• Disks 3 - 8, RAID 5 (striped), data

After doing a physical to virtual conversion/migration of one of the physical machines to a temporary VM on another existing ESX host I pulled the mirror set (OS) disks out to preserve the original OS until I was comfortable with the temporary VM. 6 disks remained and were reconfigured as a new RAID 5 array. I then rebuilt the box as a new ESX host and created virtual machines.

Later, I decided to add the 2 saved disks back into the system. After physically adding, I used the Array Configuration Utility (ACU) to add the 2 disks to the array, then expanded and extended it. However, the ESX environment will not recognize the expanded disk. The datastore properties dialog shows the local physical disk capacity as 473 GB, but the datastore shows a capacity of 336 GB. When I click the "Increase..." button, there are no paths to go down since there are no new, unallocated LUNs from which to choose. I rebooted the system several times during these steps.

Having struggled with some other issues, I decided to start from scratch. Using the ACU, I deleted the logical volume and started the host installation again. When prompted for the volume to which ESX would be installed, it showed the single volume with the expected full disk size (~470 GB). I chose that and installed. After starting the ESX host, I looked at the datastore and saw that it is still only 336 GB. However, like before, the datastore properties shows the physical file system having a capacity of 473 GB. Furthermore, and most surprising, when I browse the datastore all the files (virtual disks and such) that existed before I supposedly deleted and recreated the logical volume are still there as if nothing had happened.

I'm sure the datastore size is not limited by ESX since I have another system running version 4 that has a logical volume of around 410 GB.

Does anyone know what I'm doing wrong or if I have to do something specific within the Linux environment to get it to recognize the larger volume?