I’ve built out a generic (non-registered) VMWare SLE_12 image to allow a clone → register (via an orchestration product) → install workflow.
This works well. But since many services provide a web service (for admin or otherwise) the split of PHP et al to a separate add on package makes a manual step.
I’ve looked at two workarounds:
Trying to install the add on without registering (not too surprisingly there is no easy path for this)
Trying to use Yast at the command line to auto install. This initially seemed promising, but also does not seem to work. Yast will take a URI for the “addon” sub-command, but… this URI seems generated by the registration process.
I’m wondering whether any one else has run into this and come up with a creative solution. Thanks!
On 12/11/2015 15:44, joe fortier wrote:
[color=blue]
I’ve built out a generic (non-registered) VMWare SLE_12 image to allow a
clone → register (via an orchestration product) → install workflow.[/color]
Possibly you’ve already seen it but just in case you haven’t, SUSE last
week announced the availability of SLES12 JeOS “Just enough OS” which is
designed for such a scenario - it’s a minimal install of SLES12 which
you can then add to. A VMDK image is available to download from https://download.suse.com/Download?buildid=fzK-J1a-S5k~
[color=blue]
This works well. But since many services provide a web service (for
admin or otherwise) the split of PHP et al to a separate add on package
makes a manual step.
I’ve looked at two workarounds:
Trying to install the add on without registering (not too
surprisingly there is no easy path for this)
Trying to use Yast at the command line to auto install. This
initially seemed promising, but also does not seem to work. Yast will
take a URI for the “addon” sub-command, but… this URI seems generated
by the registration process.
I’m wondering whether any one else has run into this and come up with a
creative solution. Thanks![/color]
Do you have a local SMT server? If not that would allow you to mirror
the various extra SLES12-related repositories to then register your
local servers against.
What I would suggest is that as part of your workflow you handle the
registration to your SMT server (or it could be directly to SUSE
Customer Center) rather than as part of the “base” system. The reason
for doing this is you don’t have problems with duplicate systems in
SCC/SMT using the “base” system’s credentials - you want the credentials
to be fresh for each system.
So your workflow would register to SMT/SCC then if a PHP (for example)
is required, subscribe to Web & Scripting module, and install PHP.
HTH.
Simon
SUSE Knowledge Partner
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below. Thanks.