Using the abt.cnf based technique documented in https://www.instantiations.com/docs/91/wwhelp/wwhimpl/js/html/wwhelp.htm#href=sg/stug515.html, I've built all the logic to build the images for our applications automatically. This takes a clean image, loads in the relevant config maps, creates XD images if necessary and fires off the packager.
The issue I have is that our EMSRV library has password validation enabled (as per https://www.instantiations.com/docs/91/wwhelp/wwhimpl/js/html/wwhelp.htm#href=ig/instgd38.html) to ensure the library records which user does each change. When this is enabled, each user is prompted to enter their password when starting an image connected to this library.However, I cannot find any (official) way to allow the abt.cnf file to supply a password and thus not cause the dialog to be displayed. As the build is being done via Jenkins, there is no desktop to even show this dialog on! Basically, the build stops at this point waiting for a user to enter a password into a dialog box that is not displayed anywhere.
Once I can get my password prompt problem solved, I can give all the code for everyone else to leverage.
The basic gist of the process I want to do is 2 main steps: Take a ‘newimage’ image to a state that allows it to be used as the basis for the application builds. Then use this image repeatedly for each application build (we have 10 all up to build – 3 windows, 7 linux).
Step 1 basically does
- Copy the abt.icx from newimage
- Install an abt.ini that connects it to the library
- Install an abt.cnf that has EarlyStart logic to register the image to the build user and connect it to the library, and PostStartup logic to load in a config map containing all the VAST features we need, create an XD image and load into it the features we need and save this image
- Run this via the command line
Step 2 basically does
- Take the pre-prepared image
- Install a ‘builder’ abt.cnf which parses the command line, loads in the requested version of the application specific config map and, if the application is an XD image, load the config map into the XD image, then run the packager with a command line supplied packaging instruction (along with error checking and stopping if there is a problem)
- Sends this image off to the next build job to be included with all the rest of the application logic
Until I can get around the password problem, Step 1 is not currently automated. Right now, I do Step 1 manually and add the extra hack to EtTools to disable the password dialog so that Step 2 is fully automated. As I’m taking the clean newimage as the start of step 1, there is no opportunity to change EtTools before the password prompt comes up for it.
The EMSRV is running on windows using native authentication (-rn mode). Each user is created in the library with a network name matching their active directory name (domain\username). Each user then sets their image to be owned by their user and on startup, the image prompts them for their own password. This way all changes are tracked to the user that makes them. We are only using this for user identification rather than ‘security’ (ie all the application level security is set to World).
So each user has their own account (their network account), and the builder has been given its own network account (which is the account jenkins logs into Windows as). I know the password for the builder account and can supply it to smalltalk. I just cannot see a way to actually supply the password to EtTools so that it is happy and does not display the password modal dialog.
EtTools class>>#checkPassword:in: is what shows the dialog.
From: 'Mariano Martinez Peck' via VA Smalltalk <va-sma...@googlegroups.com>
Sent: Friday, 6 December 2019 00:37
To: VA Smalltalk <va-sma...@googlegroups.com>
Subject: Re: Automated building of an image against an EMSRV with passwords enabled
EXTERNAL: Do not click links or open attachments if you do not recognize the sender.
--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
va-smalltalk...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/va-smalltalk/CAOUkibHKLfUKhTVTnL47Cg0PCJ2YLZeKjO7KyXwp778SWUKudQ%40mail.gmail.com.
Once I can get my password prompt problem solved, I can give all the code for everyone else to leverage.
The basic gist of the process I want to do is 2 main steps: Take a ‘newimage’ image to a state that allows it to be used as the basis for the application builds. Then use this image repeatedly for each application build (we have 10 all up to build – 3 windows, 7 linux).
Step 1 basically does
- Copy the abt.icx from newimage
- Install an abt.ini that connects it to the library
- Install an abt.cnf that has EarlyStart logic to register the image to the build user and connect it to the library, and PostStartup logic to load in a config map containing all the VAST features we need, create an XD image and load into it the features we need and save this image
- Run this via the command line
Step 2 basically does
- Take the pre-prepared image
- Install a ‘builder’ abt.cnf which parses the command line, loads in the requested version of the application specific config map and, if the application is an XD image, load the config map into the XD image, then run the packager with a command line supplied packaging instruction (along with error checking and stopping if there is a problem)
- Sends this image off to the next build job to be included with all the rest of the application logic
Until I can get around the password problem, Step 1 is not currently automated. Right now, I do Step 1 manually and add the extra hack to EtTools to disable the password dialog so that Step 2 is fully automated. As I’m taking the clean newimage as the start of step 1, there is no opportunity to change EtTools before the password prompt comes up for it.
The EMSRV is running on windows using native authentication (-rn mode). Each user is created in the library with a network name matching their active directory name (domain\username). Each user then sets their image to be owned by their user and on startup, the image prompts them for their own password. This way all changes are tracked to the user that makes them. We are only using this for user identification rather than ‘security’ (ie all the application level security is set to World).
So each user has their own account (their network account), and the builder has been given its own network account (which is the account jenkins logs into Windows as). I know the password for the builder account and can supply it to smalltalk. I just cannot see a way to actually supply the password to EtTools so that it is happy and does not display the password modal dialog.
EtTools class>>#checkPassword:in: is what shows the dialog.
Using the abt.cnf based technique documented in https://www.instantiations.com/docs/91/wwhelp/wwhimpl/js/html/wwhelp.htm#href=sg/stug515.html, I've built all the logic to build the images for our applications automatically. This takes a clean image, loads in the relevant config maps, creates XD images if necessary and fires off the packager.The issue I have is that our EMSRV library has password validation enabled (as per https://www.instantiations.com/docs/91/wwhelp/wwhimpl/js/html/wwhelp.htm#href=ig/instgd38.html) to ensure the library records which user does each change. When this is enabled, each user is prompted to enter their password when starting an image connected to this library.However, I cannot find any (official) way to allow the abt.cnf file to supply a password and thus not cause the dialog to be displayed. As the build is being done via Jenkins, there is no desktop to even show this dialog on! Basically, the build stops at this point waiting for a user to enter a password into a dialog box that is not displayed anywhere.
Thanks Mariano. I was hoping to not have to replace any core methods and keep the password check - just allowing the automation to supply the password directly. I'm currently replacing EtTools class>>#startUp but could do EmLibrary class>>#isPasswordCheckingEnabled instead.
The way either of these are working means that anyone can take the intermediate image and use it to access the library without any authentication though. I did EtTools class>>#startUp to just disable the startup password prompt, but leave in the change user password prompt, in case someone did take the image and try to use it for manual purposes. I was hoping I could tell EtTools the password or authenticate to the library such that EtTools didn't prompt - but that doesn't seem possible.
Most of the rest of what you said is already in the process I'd rigged up although I'm using the PostStartup system rather than the fork/polled wait system as I am currently using 9.1.
For Richard, the "EmUser current: (EmUser called: 'Build User')" line will stop the image prompting for the owner of a new image, but not the password for that user if the image is connected to a password enabled library which is the prompt I'm trying to avoid.I'll create a new post in the next little while with the solution I have created so others can leverage it and improve it.