This week on the podcast, Kyle shares more information about systemd User Services, Dan discusses some recent DPK improvements, and then they discuss the upcoming changes to Job Data’s user interface.
This week on the podcast, Kyle and Dan talk about the new OCI Cloud Shell, Cloud Manager 10 installation and configuration videos, learning keyboard shortcuts, and debugging failed Windows services.
A common theme we write about on the blog is how to make the DPK work with multiple environments on the same machine. It’s common to run a DEV and TST on the same server. The DPK can build those environments, but there are a few changes to make the setup run well. On Windows, the services the DPK creates makes an assumption that breaks when we run multiple environments.
When starting a domain via Windows services, the service assumes that the environment variables are set for that environment. If you create your DEV environment via the DPK, that’s a good assumption. But, if you create a TST environment next, the environment variables are set to TST. When you attempt to start the DEV domain via Windows services, the domain start will fail.
To resolve this, we can improve the Ruby script that starts our domains. Under the
ps_cfg_home\appserv\DOMAIN folder, there are Ruby scripts that are called by the Windows service. For the app server, it’s
appserver_win_service.rb. These scripts will look for the
PS_CFG_HOME environment variable and start the domains it finds under that home. We can add a line in the file to point to the correct
PS_CFG_HOME location like this:
While we can modify the file directly, the DPK way of handling this is to update the template in the DPK. Then, whenever we rebuild our domains the code change is automatically included.
The Ruby scripts to start/stop domains are templates in the DPK. The templates are stored under
pt_pia for the batch and PIA services.)
To make the environment variables we add dynamic, we can reference variables that exist in the Ruby environment that calls the ERB template. In the program
appserver_domain_boot.rb, the variables
ps_cfg_home are set. We will use those variables to build our environment variables.
ENV["PS_HOME"] = "<%= ps_home %>" ENV["PS_CFG_HOME"] = "<%= ps_cfg_home %>" system("<%= ps_home %>/appserv/psadmin -c start -d <%= domain_name %>")
<%= %> tags will output the value of that command or variable. So in our case, we are outputting the string value of
The result of this file will look like this:
ENV["PS_HOME"] = "c:\\psft\\pt\ps_home8.56.08" ENV["PS_CFG_HOME"] = "c:\\psft\\cfg\\DEV" system("c:\\psft\\pt\ps_home8.56.08\\appserv\\psadmin -c start -d DEV")
When we run Puppet the next time, our Windows service will have it’s environment variables set before starting or stopping a domain.