A quick couple of UrbanCode Deploy tips, one on getting the SSH config right and the other on using the UCD agent and/or CLI provide an access work around.
1. Installing an agent on Unix from a Windows UCD Server
As with the somewhat dubious art of skinning cats, there are a few different ways to install UCD agents on target systems: from an installation package, using the UCD CLI, or, if installing to a Unix system, from the UCD server web application.
I like simplicity so I spurned the first two methods and assumed that the third would be the simplest. It was. Almost.
I made sure I had
JAVA_HOME set and SSH installed and working on one of the Linux servers. Went to the UCD server web application, clicked Home > Resources > Agents < Install New Agent and filled out the dialog with the appropriate values.
Clicked Save and couple of seconds later was presented with an unpleasant error:
"Error installing agent to rhel6x6401.freddy.net. Could not load known_hosts"
When I installed the UCD server on a Windows 2008 Server I chose to have the Windows service for the server use the “LOCAL SYSTEM” as the user account. Putting a
known_hosts file under the Administrator’s %USERPROFILE%\.ssh directory had no effect. And of course I could connect to the Linux server vi SSH using Putty with no problems.
It turns out that the %USERPROFILE% directory for the Local System “user” is located at
C:\Windows\System32\Config. So I added an .ssh directory, put a known_hosts file in there and bingo!: the agent installed and fired up with no further issues.
2. No access? No worries. Use an Agent or the CLI
UrbanCode Deploy pulls artifacts into Components from somewhere, usually one of the Source Config types. What if none of the Source Config Types apply? What if even the File System types won’t work because the file system where the artifacts are stored by some “packaging system” are inaccessible from the UCD server via the usual (NFS, Samba, SMB etc.) mechanisms?
Option 1: Put a UCD agent on the packaging server with the files on it and make it work like a pseudo Source Config type using the Create Versions step from the UCD Versions Plugin.
Both these options are often easier than having to install and configure Samba for example. Both options allow invocation directly from the “packaging system”. Option 1 is a little nicer because it can be part of a process. If defined as an Operational Process for the component then a “SOURCE” pseudo-environment mapped to the agent on the file server system can be defined for the process to be run on. Alternatively it could be defined as a Generic Process and run without the environment definition.
An additional benefit of using one of these options is the flexibility to construct a custom Version Name beyond the Version Name Pattern for File System (Basic) Source Config type or the sub-directory name for the File System (Versioned) Source Config type.