[sles-beta] SLES12 x86_64 RC2 autoyast post-script zypper unusable, application locked by y2base
Richard Brown
rbrown at suse.de
Wed Aug 27 06:36:27 MDT 2014
On Wed, 2014-08-27 at 11:54 +0000, urs.frey at post.ch wrote:
> Hello Stefan
>
> The way to add add-on product repositories is well known to me, thank you very much.
>
> BUT:
> As I mentioned I am using puppet and a CMDB.
> So my puppet modules when running will make sure, the correct software package depending the configuration requirements will be installed.
>
> So it is not the same as e.g:
> Autoyast post-script = >zypper in -y apache2, or zypper in -y mypackage
>
> It works this way
>
> /usr/bin/puppet agent --server=vpup02.pnet.ch --masterport=8140 --environment=config_development -v --no-daemonize --onetime --http_compression --libdir=/var/lib/puppet/lib/config_development --color=false --show_diff
If this is the case, why can you not have puppet control the system in
the way you require?
One way you could see this issue is that AutoYAST's job is to "get the
system installed and usable as fast as possible"
This is complimented by systemd's logic which is to "get the installed
system booted and usable as fast as possible"
The behaviour you describe as 'broken' and 'unusable' seems to me to be
desirable in many cases, even with use cases like puppet, where many
people rely on the asyncronous nature of puppet to handle and resolve
issues in the background while users go about their business.
Obviously, you need a solution for this specific case, but I cant help
but ask 'why not use puppet'?
Puppet can control both systemd services, user accounts, configured
authentication methods, etc.
If your desire is to make sure that users dont use the system until your
initial puppet run is complete, why not use puppet to prevent your
overly keen administrators getting on the system until it's ready?
Regards,
Richard
>
>
> And within the puppet manifest we have:
> ==========================
> class admin::mcollective( $p_mco_admins = [] ) {
>
> $mcollective_classesfile = '/var/lib/puppet/classes_config.txt'
> if ( $::operatingsystem == 'SLES' and $::is_in_postinstallscript == 'false' ) {
> if ( $::operatingsystemrelease >= 11 ) {
> package {'pst-rubygem-stomp':
> ensure => latest,
> notify => Service['mcollective'],
> } ->
> package {'pst-rubygem-sshkeyauth':
> ensure => latest,
> notify => Service['mcollective'],
> } ->
> package {'pst-mcollective-server':
> ensure => latest,
> notify => Service['mcollective'],
> alias => 'mcollective-server',
> }
> } else {
> package {'pst-rubygem-sshkeyauth':
> ensure => installed,
> notify => Service['mcollective'],
> } ->
> package {'pst-mcollective-server':
> ensure => installed,
> notify => Service['mcollective'],
> alias => 'mcollective-server',
> }
> }
> if ( $::architecture == 'x86_64' ) {
> if ( $::operatingsystemrelease >= 12 ) {
> $mcollective_libdir = '/usr/lib64/ruby/site_ruby/2.1.0/x86_64-linux-gnu/mcollective.plugins:/etc/mcollective/plugin.d'
> } else {
> $mcollective_libdir = '/usr/lib64/ruby/site_ruby/1.8/x86_64-linux/mcollective.plugins:/etc/mcollective/plugin.d'
> }
> } else {
> $mcollective_libdir = '/usr/lib/ruby/site_ruby/1.8/i586-linux/mcollective.plugins:/etc/mcollective/plugin.d'
> }
>
>
> Best regards
>
>
> Urs Frey
> Post CH AG
> Informationstechnologie
> IT Betrieb
> Webergutstrasse 12
> 3030 Bern (Zollikofen)
> Telefon : ++41 (0)58 338 58 70
> FAX : ++41 (0)58 667 30 07
> E-Mail: urs.frey at post.ch
>
>
> -----Ursprüngliche Nachricht-----
> Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Stefan Schubert
> Gesendet: Wednesday, August 27, 2014 12:56 PM
> An: sles-beta at lists.suse.com
> Betreff: Re: [sles-beta] SLES12 x86_64 RC2 autoyast post-script zypper unusable, application locked by y2base
>
> Hi,
> the normal way of installingadditional and customized packages in
> autoyast is defined
> here:
> http://doc.opensuse.org/projects/autoyast/configuration.html#idm139795987981568
>
> It seem that this way does not fit your requirements. OK, here is a
> really HACK.
> Libzypp (which is used by zypper) just checks the file /var/run/zypp.pid
> in order
> checking the lock. (which is blamed by zypper).
> So you would only have to move this file to other position, call your
> zypper calls
> and please move this file back after you have finished your zypper calls.
> But as I have already said, this is REALLY a hack and should NOT be the
> normal way:-)
>
> Greetings
> Stefan Schubert
>
>
> g155:/home/src/ISOs # cat /var/run/zypp.pid
> 13544
> g155:/home/src/ISOs # ps aux|grep 13544
> root 13544 14.6 5.9 878604 235540 pts/20 Sl+ 12:40 0:10
> /usr/lib/YaST2/bin/y2base sw_single qt
> root 14047 0.0 0.0 9264 928 pts/21 S+ 12:41 0:00 grep
> --color=auto 13544
>
>
>
> Am 27.08.2014 11:10, schrieb urs.frey at post.ch:
> > Hi
> > I am trying to install SLES12 x86_64 RC2 onto my testservers using
> > autoyast
> > I have a bunch of package installations and configurations to do,
> > which are configured by puppet.
> > During autoyast post-script phase zypper unfortunately is locked by
> > y2base process
> > root 603 1 0 10:53 tty7 00:00:00 /bin/sh
> > /usr/lib/YaST2/startup/YaST2.Second-Stage
> > root 4040 603 0 10:54 tty7 00:00:00 /bin/sh
> > /usr/lib/YaST2/startup/YaST2.call installation continue
> > root 4742 4040 27 10:54 tty7 00:00:11 y2base installation
> > ("continue") ncurses
> > root 7597 4742 0 10:54 tty7 00:00:00 [snapper.py] <defunct>
> > root 9337 4742 0 10:54 tty7 00:00:00 y2base installation
> > ("continue") ncurses
> > root 9338 9337 0 10:54 tty7 00:00:00 y2base installation
> > ("continue") ncurses
> > root 9339 9338 0 10:54 tty7 00:00:00 sh -c /bin/sh -x
> > /var/adm/autoinstall/scripts/post-script.sh &>
> > /var/adm/autoinstall/logs/post-script.sh.log
> > root 9340 9339 0 10:54 tty7 00:00:00 /bin/sh -x
> > /var/adm/autoinstall/scripts/post-script.sh
> > root 9693 9340 0 10:54 tty7 00:00:00 ps -efww
> > So when having a look at the processes together with y2base I quickly
> > get the intention, that the second stage of autoyast itself, showing
> > the ncurses screen is the y2base process. So killing of y2base would
> > not be a good idea to gain zypper access.
> > So for me going back to RPM package installation to omit zypper
> > conflict within autoyast post-script is not an option.
> > Moving the entire puppet configuration and OEM package installation to
> > autoyast init-script seems to be the only way.
> > But autoyast init-script on the other hand does run in the background
> > while systemD already opens the console login for root.
> > Having console logins already enabled, while autoyast init-script is
> > still running is really not a good way.
> > regards
> > Urs Frey
> > Post CH AG
> > Informationstechnologie
> > IT Betrieb
> > Webergutstrasse 12
> > 3030 Bern (Zollikofen)
> > Telefon : ++41 (0)58 338 58 70
> > FAX : ++41 (0)58 667 30 07
> > E-Mail: _urs.frey at post.ch_ <mailto:urs.frey at post.ch>
> >
> >
> > _______________________________________________
> > sles-beta mailing list
> > sles-beta at lists.suse.com
> > http://lists.suse.com/mailman/listinfo/sles-beta
>
>
--
Richard Brown
QA Engineer
openSUSE Chairman
Phone +4991174053-361
SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg
Geschaeftsfuehrer: Jeff Hawn, Jennifer Guild, Felix Imendoerffer, HRB 16746 (AG Nuernberg)
More information about the sles-beta
mailing list