Last week Wilfred and I spent some time to understand why the Maven2
mvn site:deploy command would not work when
scp was used to access the target server. Based on the documentation we put:
<servers> <server> <id>server-id</id> <username>gumpy</username> <password>hushhush</password> </server> </servers>in the
~/.m2/settings.xmlfile and included
<distributionManagement> <site> <id>server-id</id> <name>Deployment Server</name> <url>scp://server-id.domain.com/home/gumpy/projects/</url> </site> </distributionManagement>in the projects POM. Looks OK, right? Well, while using commandline
sshworks using the credentials above,
mvn site:deployfails saying it cannot authenticate (and lists the supported authentication methods).
After a number of attempts we decided to try the private key authentication method in combination with an external scp command. This worked! It might not be what you want in the end, but at least we could continue. Small advantage of this solution might be that you don't have to include a password in your
~/.m2/settings.xml file. On the other hand, everybody who wants to deploy the site has to get their public key included in the servers
~/.ssh/authorized_keys file, which might be a disadvantage.
<servers> <server> <id>server-id</id> <username>gumpy</username> </server> </servers>And this is the projects POM snippet (note that
scpexeindicates that an external
scpcommand must be used):
<distributionManagement> <site> <id>server-id</id> <name>Deployment Server</name> <url>scpexe://server-id.domain.com/home/gumpy/projects/ </site> </distributionManagement> <build> <extensions> <extension> <groupId>org.apache.maven.wagon</groupId> <artifactId>wagon-ssh-external</artifactId> <version>1.0-alpha-5</version> </extension> </extensions> ... </build>In addition to these changes to the
settings.xmland the projects POM file we had to include the SSH public key of our development machines in the
.ssh/authorized_keys2file of the "gumpy" user on the
server.domain.commachine. A howto for "SSH without a password can be found here.
I suspect that the above is just a temporary workaround till the Maven 2 site:deploy plugin is fixed.
Earlier this week I upgraded two of my mission critical machines. The first one was a planned upgrade. My server at home (which is hosting the blog) was still running RedHat 9 and time and time again I ran into packages that would not install. I was a afraid that it would take me days to get everything (Apache, Tomcat, IDS, imap server, ...) up and running again, but was pleasantly surprised! I upgraded to < a href="http://fedora.redhat.com/">Fedora Core 4 and the upgrade went like a breeze. The Fedora installer asked me if I'd like to upgrade and it did almost everything correct for me. The thing I had to fix manually were:
- The mod_jk module for Apache
- The IMAP server. I don't remember the name of the IMAP server that was included in RedHat 9, but Fedora included Dovecot and that was real easy to install and run
- For IDS one of the Perl modules was missing (Image::Info), using CPAN that was fixed quickly
The other machine I upgraded was my laptop. This was not a planned action :-( The laptop was running Solaris 10 and I tried to mount an unused partition on the harddisk since I needed some extra space. I tried to do this using fdisk, but somewhere I must have made a mistake. After a reboot the machine wouldn't start anymore and even trying to fix it by booting from the installation DVD would not work. The only thing I could do was to completely reinstall the machine.... Data lost? Not really, it happened on Monday and I usually run a backup of the data on my laptop during the weekend :-) That's a good habit. The laptop is now up and running again, no more Solaris 10, but Nevada. Nevada (codename for development of Solaris 11) has even better support for laptops and since I did have to reinitialize the whole machine anyway, why not go for something cool? After installing the OS I added all my favorite applications using pkg-get from Blastwave. Really convenient.
Back to work...