Jira (PUP-4012) parsed provider destroys file if a line starts with uppercase Q
Title: Message Title Stefan Schulte created an issue Puppet / PUP-4012 parsed provider destroys file if a line starts with uppercase Q Issue Type: Bug Affects Versions: PUP 3.7.3 Assignee: Stefan Schulte Components: Types and Providers Created: 2015/02/13 10:13 AM Priority: Major Reporter: Stefan Schulte if a record in a file starts with an uppercase Q, puppet will merge this line with the previous line when the file is written back to disc, making the file invalid. I know this sounds weired def lines(text) # Remove any trailing separators, and then split based on them
Jira (PUP-4012) parsed provider destroys file if a line starts with uppercase Q
Title: Message Title Stefan Schulte commented on PUP-4012 Re: parsed provider destroys file if a line starts with uppercase Q yep. When one of our DBAs told me puppet would mangle the `/var/opt/oracle/oratab` file but only if the database starts with a Q I was staring at the screen in disbelief Add Comment This message was sent by Atlassian JIRA (v6.3.10#6340-sha1:7ea293a) -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4012) parsed provider destroys file if a line starts with uppercase Q
Title: Message Title Stefan Schulte commented on PUP-4012 Re: parsed provider destroys file if a line starts with uppercase Q in case you haven't noticed already: I have attached a pull request for this one. Add Comment This message was sent by Atlassian JIRA (v6.3.10#6340-sha1:7ea293a) -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4012) parsed provider destroys file if a line starts with uppercase Q
Title: Message Title Stefan Schulte commented on PUP-4012 Re: parsed provider destroys file if a line starts with uppercase Q yeah I also didn't find anything in the code history what the `sub` method intention is. If it is just trailing delimiters, the split already does the job. If it is intended to do something else, it has never worked. AFAIK in perl `\Qsomehing\E` causes something to be treated literal - e.g. if line_seperator would be a simple `.` it will not suddenly match EVERY character. But then the `sub` method would remove every line_seperator which also does not make any sense. So for now I'll go with never worked - obviously not needed Add Comment This message was sent by Atlassian JIRA (v6.3.10#6340-sha1:7ea293a) -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-2771) service status field behaves exactly other way than documentation
Title: Message Title
Stefan Schulte commented on an issue
Re: service status field behaves exactly other way than documentation
yes you are right. But if you just parse the process list you can actually just say
service { 'my-service':
ensure= running,
hasstatus = false,
}
And puppet will look for a process my-service (or use the pattern parameter if the process name differs from the service name). This should at least be easier to read.
Do you think we can close the issue?
Add Comment
Puppet / PUP-2771
service status field behaves exactly other way than documentation
Jira (PUP-2771) service status field behaves exactly other way than documentation
Title: Message Title
Stefan Schulte commented on an issue
Re: service status field behaves exactly other way than documentation
I cannot reproduce the issue here
The following snippet will not start the service (/bin/true returns 0)
service { 'my-service':
ensure= running,
hasstatus = false,
status= /bin/true
}
The following snippet will start the service (/bin/false always returns 1)
service { 'my-service':
ensure= running,
hasstatus = false,
status= /bin/false
}
Is it possible that your status command does always return the grep output so you will always end up with at least one line?
% ps fax | grep my-service
2530 pts/0S+ 0:00 \_ grep --colour=auto my-service
Add Comment
Puppet / PUP-2771
service status field behaves exactly other way than documentation
The documentation states at http://docs.puppetlabs.com/references/latest/type.html#service-attribute-status {quote} status Specify a status command manually. This command must return 0 if the service is running and a nonzero value otherwise. {quote} But in fact it is *exactly the other way round*. For a non running service to be started the
Jira (FACT-608) Facter deliver wrong architecture to puppet
Title: Message Title Stefan Schulte moved an issue Facter / FACT-608 Facter deliver wrong architecture to puppet Change By: Stefan Schulte Component/s: Modules Affects Version/s: 3.3.2 Key: PUP FACT - 1548 608 Project: Puppet Facter Add Comment This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-1548) Facter deliver wrong architecture to puppet
Title: Message Title
Stefan Schulte commented on an issue
Re: Facter deliver wrong architecture to puppet
Hi Bjoern,
I'm sorry that it took so long. This issue looks familiar to me and it is a know issue between facter 1.6.2 and 1.6.9. It has been fixed in 1.6.9. See old redmine ticket #11511 for reference
The main problem here is that there probably is a fact recursion (fact a depends on fact b depends on fact a) which facter silently ignored up to version 1.7.0 (as described in old redmine ticket #12790https://projects.puppetlabs.com/issues/12790)
The 1.6.x branch is pretty old though and not supported anymore (see http://docs.puppetlabs.com/facter) so please consider upgrading
Add Comment
Puppet / PUP-1548
Facter deliver wrong architecture to puppet
I got this params.pp {noformat} case $::operatingsystem{ 'Debian', 'Ubuntu': { $package_name = SnareLinux-3.0.0-2_$::architecture.deb $provider = 'dpkg' $install_name = 'snarelinux' } {noformat} On Ubuntu Client puppet says: {noformat} root@PC3214ub:~# puppet agent -t info: Retrieving plugin ...
This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)
Jira (PUP-1548) Facter deliver wrong architecture to puppet
Title: Message Title
Stefan Schulte commented on an issue
Re: Facter deliver wrong architecture to puppet
do you agree, that this issue can be closed?
Add Comment
Puppet / PUP-1548
Facter deliver wrong architecture to puppet
I got this params.pp {noformat} case $::operatingsystem{ 'Debian', 'Ubuntu': { $package_name = SnareLinux-3.0.0-2_$::architecture.deb $provider = 'dpkg' $install_name = 'snarelinux' } {noformat} On Ubuntu Client puppet says: {noformat} root@PC3214ub:~# puppet agent -t info: Retrieving plugin ...
This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)
--
You received this message because you are subscribed to the Google Groups Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (PUP-1548) Facter deliver wrong architecture to puppet
Title: Message Title Stefan Schulte assigned an issue to Bjoern Puppet / PUP-1548 Facter deliver wrong architecture to puppet Change By: Stefan Schulte Assignee: AndyParker Bjoern Add Comment This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-1548) Facter deliver wrong architecture to puppet
Title: Message Title
Stefan Schulte commented on an issue
Re: Facter deliver wrong architecture to puppet
Hi Bjoern,
thanks for the input. Can you please add the facter version as well?
Add Comment
Puppet / PUP-1548
Facter deliver wrong architecture to puppet
I got this params.pp {noformat} case $::operatingsystem{ 'Debian', 'Ubuntu': { $package_name = SnareLinux-3.0.0-2_$::architecture.deb $provider = 'dpkg' $install_name = 'snarelinux' } {noformat} On Ubuntu Client puppet says: {noformat} root@PC3214ub:~# puppet agent -t info: Retrieving plugin ...
This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)
--
You received this message because you are subscribed to the Google Groups Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (PUP-1548) Facter deliver wrong architecture to puppet
Title: Message Title
Stefan Schulte commented on an issue
Re: Facter deliver wrong architecture to puppet
what facter version are you running on your agent (facter --version)?
Add Comment
Puppet / PUP-1548
Facter deliver wrong architecture to puppet
I got this params.pp {noformat} case $::operatingsystem{ 'Debian', 'Ubuntu': { $package_name = SnareLinux-3.0.0-2_$::architecture.deb $provider = 'dpkg' $install_name = 'snarelinux' } {noformat} On Ubuntu Client puppet says: {noformat} root@PC3214ub:~# puppet agent -t info: Retrieving plugin ...
This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)
--
You received this message because you are subscribed to the Google Groups Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (PUP-1548) Facter deliver wrong architecture to puppet
Title: Message Title
Stefan Schulte updated an issue
Puppet / PUP-1548
Facter deliver wrong architecture to puppet
Change By:
Stefan Schulte
Igotthisparams.pp {noformat} case$::operatingsystem{'Debian','Ubuntu':{$package_name=SnareLinux-3.0.0-2_$::architecture.deb$provider='dpkg'$install_name='snarelinux'} {noformat} OnUbuntuClientpuppetsays: {noformat} root@PC3214ub:~#puppetagent-tinfo:Retrievingplugininfo:Loadingfactsin/var/lib/puppet/lib/facter/root_home.rbinfo:Loadingfactsin/var/lib/puppet/lib/facter/puppet_vardir.rbinfo:Loadingfactsin/var/lib/puppet/lib/facter/vmwaretools_version.rbinfo:Loadingfactsin/var/lib/puppet/lib/facter/pper_installed.rbinfo:Loadingfactsin/var/lib/puppet/lib/facter/pe_version.rbinfo:Loadingfactsin/var/lib/puppet/lib/facter/os_maj_version.rbinfo:Loadingfactsin/var/lib/puppet/lib/facter/environment.rbinfo:Loadingfactsin/var/lib/puppet/lib/facter/facter_dot_d.rbinfo:Cachingcatalogforpc3214ubinfo:Applyingconfigurationversion'1391100647'err:/Stage[main]/Snare/File[/usr/local/src/SnareLinux-3.0.0-2_x86_64.deb]:Couldnotevaluate:Couldnotretrieveinformationfromenvironmentproductionsource(s)puppet:///modules/snare/SnareLinux-3.0.0-2_x86_64.debat/etc/puppet/modules/snare/manifests/init.pp:17notice:/Stage[main]/Snare/Package[installsnare]:DependencyFile[/usr/local/src/SnareLinux-3.0.0-2_x86_64.deb]hasfailures:truewarning:/Stage[main]/Snare/Package[installsnare]:Skippingbecauseoffaileddependenciesnotice:/Stage[main]/Snare/File[/etc/audit/snare.conf]:DependencyFile[/usr/local/src/SnareLinux-3.0.0-2_x86_64.deb]hasfailures:truewarning:/Stage[main]/Snare/File[/etc/audit/snare.conf]:Skippingbecauseoffaileddependenciesnotice:/Stage[main]/Snare/File[/etc/snare.conf]:DependencyFile[/usr/local/src/SnareLinux-3.0.0-2_x86_64.deb]hasfailures:truewarning:/Stage[main]/Snare/File[/etc/snare.conf]:Skippingbecauseoffaileddependenciesnotice:Finishedcatalogrunin11.03seconds {noformat} FacteronUbuntuClientsays: {noformat} root@PC3214ub:~#facterarchitectureamd64 {noformat} Thearchitectureis {{ amd64 }} butpuppetagentislookingfor {{ x86_64 }} .Thefileforamd64ispresent: {noformat} ll/etc/puppet/modules/snare/files/insgesamt283K-rw-rw-r--+1beckerbbeckerb42117.Okt12:55snare.conf-rw-rw-r--+1beckerbbeckerb59K17.Okt15:18SnareLinux-2.1.0-1.x86_64.rpm-rw-rw-r--+1beckerbbeckerb54K17.Okt13:41SnareLinux-3.0.0-1.i386.rpm-rw-rw-r--+1beckerbbeckerb56K17.Okt12:16SnareLinux-3.0.0-1.x86_64.rpm-rw-rw-r--+1beckerbbeckerb52K17.Okt12:15SnareLinux-3.0.0-2_amd64.deb-rw-rw-r--+1beckerbbeckerb50K17.Okt14:57SnareLinux-3.0.0-2_i386.deb {noformat} Myclientversionis: {noformat} root@PC3214ub:~#puppet--version2.7.11 {noformat} I'mnotsuretobecorrecthere,butIguessthisisabug..
Add Comment
Jira (PUP-1402) PR (2233): Issue/stable/pup 736 remove rpm dpkg description fetching - jpartlow
Title: Message Title Stefan Schulte updated an issue Puppet / PUP-1402 PR (2233): Issue/stable/pup 736 remove rpm dpkg description fetching - jpartlow Change By: Stefan Schulte Fix Version/s: 3.4.3 Add Comment This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-1225) Puppet does not specify encoding when setting up rails database connection
Title: Message Title Stefan Schulte commented on an issue Re: Puppet does not specify encoding when setting up rails database connection I searched if this is a known issue in ruby but all I found is the following issue: https://bugs.ruby-lang.org/issues/9414 Add Comment Puppet / PUP-1225 Puppet does not specify encoding when setting up rails database connection Hi, I want to install puppet on Windows Server 2003. I already have a working Puppetmaster (Scientific Linux). I installed puppet the way it's explained here: http://projects.puppetlabs.com/projects/1/wiki/Puppet_Windows It worked moving files locally via puppet for example. But when I try to run puppet via Puppetmaster I always get the follo... This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit
Jira (PUP-1225) Puppet does not specify encoding when setting up rails database connection
Title: Message Title Stefan Schulte commented on an issue Re: Puppet does not specify encoding when setting up rails database connection I have a similar issue with the timezone fact on a german windows system. I am using puppet `3.4.2` and the bunlded ruby that comes with the installation. I tried to backport FACT-134 which enforces UTF-8 encoding in facter, but I still got garbage in the stored /var/lib/puppet/yaml/facts file on my master. But if I get this right ruby guesses the inital encoding wrong. Here is a simple irb session with the bundled ruby in puppet 3.4.2 irb(main):017:0 puts Time.now.zone Mitteleuropische Zeit = nil irb(main):018:0 puts Time.now.zone.encoding CP850 = nil irb(main):019:0 puts Time.now.zone.encode(UTF-8, CP850) Mitteleuropische Zeit = nil irb(main):020:0 puts Time.now.zone.encode(UTF-8, CP1252) Mitteleuropische Zeit = nil The last output is the correct one, so it seem Tome.now.zone is encoded as CP1252 while ruby treats it as it was encoded as CP850. Am I missing something here? Add Comment Puppet / PUP-1225 Puppet does not specify encoding when setting up rails database connection Hi, I want to install puppet on Windows Server 2003. I already have a working Puppetmaster (Scientific Linux). I installed puppet the way it's explained here: http://projects.puppetlabs.com/projects/1/wiki/Puppet_Windows It worked moving files locally via puppet for example. But when I try to run puppet via Puppetmaster I always get the follo...
Jira (FACT-234) Add Facts showing the UUID of partitions
Title: Message Title Stefan Schulte updated an issue Facter / FACT-234 Add Facts showing the UUID of partitions Change By: Stefan Schulte Fix Version/s: 2.0 Add Comment This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.
Jira (PUP-1602) value validation of parameter managehome is broken
Title: Message Title
Stefan Schulte created an issue
Puppet / PUP-1602
value validation of parameter managehome is broken
Issue Type:
Bug
Affects Versions:
2.7.24
Assignee:
Stefan Schulte
Components:
Types and Providers
Created:
06/Feb/14 12:26 PM
Priority:
Normal
Reporter:
Stefan Schulte
The user type defines a managehome parameter that can be either true of false. Unfortunately no validation happens so you can specify
user { 'foo':
ensure = present,
managehome = 'yes', # will not create directory
}
user { 'bar':
ensure = present,
managehome = 'foo', # will not create directory
}
both validate to false apparently.
While the type resource already specifies a value list that sets up a proper validate method
newvalues(:true, :false)
the type does also define a custom validate method that will overwrite the checks that would normally take place:
Jira (PUP-677) ssh_authorized_key can't handle numeric usernames
Title: Message Title
Stefan Schulte commented on an issue
Re: ssh_authorized_key can't handle numeric usernames
The manpage states
Usernames must start with a lower case letter or an underscore, followed by lower case letters, digits, underscores, or dashes. They can end with a dollar sign. In regular _expression_ terms: [a-z_][a-z0-9_-]*[$]?
So I don't think that numeric usernames is something puppet should be able to handle. Puppet will just assume it is a UID. Let's say you define
user { foo:
uid = 100,
gid = 100,
}
Now let's suppose if there is a group foo with gid 100 and also a group with the name 100? What should puppet do then?
Add Comment
Puppet / PUP-677
ssh_authorized_key can't handle numeric usernames
A purely numeric username is a bit ridiculous, but it actually came up in a training class. A student assigned himself the username of '1970' and things blew up. Testing indicates that this resource type or provider cannot handle a numeric username. {code} [root@monkey ~]# puppet resource user 1970 ensure=present managehome=true Notice: /User[1970]/e...
This message was sent by
Jira (PUP-677) user type accepts numeric usernames, but ssh_authorized_key does not
Title: Message Title
Stefan Schulte commented on an issue
Re: user type accepts numeric usernames, but ssh_authorized_key does not
I agree that the user type should do stricter validation. But there is also the possibility that you create the user manually - and obviously some useradd implementations allow you to create a users that the man page states are invalid - and you now stumble across the ssh_authorized_key type that cannot handle the ssh keys of your manually created user.
So while we cannot ensure that you don't have users that are purely numeric, I think we should not try to handle these cases. Again: I have nothing against stricter validations for the user type but I don't now if the user should be non numeric applies for all platforms (windows?)
Add Comment
Puppet / PUP-677
user type accepts numeric usernames, but ssh_authorized_key does not
A purely numeric username is a bit ridiculous, but it actually came up in a training class. A student assigned himself the username of '1970' and things blew up. Testing indicates that this resource type or provider cannot handle a numeric username. {code} [root@monkey ~]# puppet resource user 1970 ensure=present managehome=true Notice: /User[1970]/e...
This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)
Jira (FACT-90) (#22944) External facts are evaluated many times
Title: Message Title
Stefan Schulte updated an issue
Facter / FACT-90
(#22944) External facts are evaluated many times
Change By:
Stefan Schulte
** Reproduction ** : #Dropscript{{/etc/facter/facts.d/test.sh}}:{noformat}#!/bin/bashechoSCRIPTCALLED2echotest=value{noformat}#Makescriptexecuteable{noformat}chmod+x/etc/facter/facts.d/test.sh{noformat}Call{{facter}},thefollowingoutputisshown:{noformat}root@puppet:~#facterSCRIPTCALLEDSCRIPTCALLEDSCRIPTCALLEDSCRIPTCALLEDSCRIPTCALLEDSCRIPTCALLED...Regularfacteroutput...{noformat}Idon'tseeareasonwhythescriptiscalled6times.Systeminformation*Ubuntu12.04.3*Facter1.7.3
Add Comment
This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)
--
You received this message because you are subscribed to the Google Groups Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.
Jira (FACT-90) (#22944) External facts are evaluated many times
Title: Message Title
Stefan Schulte updated an issue
Facter / FACT-90
(#22944) External facts are evaluated many times
Change By:
Stefan Schulte
**Reproduction** * # Dropscript {{ /etc/facter/facts.d/test.sh }} : pre {noformat} #!/bin/bashechoSCRIPTCALLED2echotest=value /pre {noformat} * # Makescriptexecuteable pre {noformat} chmod+x/etc/facter/facts.d/test.sh /pre {noformat} * Call ' {{ facter ' }} ,thefollowingoutputisshown: pre {noformat} root@puppet:~#facterSCRIPTCALLEDSCRIPTCALLEDSCRIPTCALLEDSCRIPTCALLEDSCRIPTCALLEDSCRIPTCALLED...Regularfacteroutput... /pre {noformat} Idon'tseeareasonwhythescriptiscalled6times.Systeminformation*Ubuntu12.04.3*Facter1.7.3
Add Comment
This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)
--
You received this message because you are subscribed to the Google Groups Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.
Jira (FACT-197) processorcount counting CPU cores on Solaris
Title: Message Title Stefan Schulte created an issue Facter / FACT-197 processorcount counting CPU cores on Solaris Issue Type: Bug Affects Versions: 1.7.4 Assignee: Eric Sorenson Created: 11/Jan/14 3:02 AM Environment: Solaris 5.10; Solaris 5.11 Priority: Normal Reporter: Stefan Schulte The processorcount fact on Solaris is counting CPU cores physicalprocessorcount = 1 processor0 = SPARC-T4 processor1 = SPARC-T4 processor2 = SPARC-T4 processor3 = SPARC-T4 processorcount = 1 and on linux it counts CPU threads. This was reported as http://projects.puppetlabs.com/issues/18215 and a working fix is currently in master. However it is not released yet as the old ticket claims, because the linked backport in the redmine ticket does not seem to have anything to do with the original issue (the backport only touches code for HP-UX)
Jira (FACT-155) Facter in Solaris 10 behaves differently from Solaris 11
Title: Message Title
Stefan Schulte commented on an issue
Re: Facter in Solaris 10 behaves differently from Solaris 11
created pull request: https://github.com/puppetlabs/facter/pull/594
Add Comment
Facter / FACT-155
Facter in Solaris 10 behaves differently from Solaris 11
Facter behaves differently in Solaris 10 and 11. I would expect operatingsystemrelease to be the major release of the operating system. This is how it works in Solaris 11. However not in Solaris 10. In Solaris 10 it outputs the update version which is very irrelevant depending on patch levels of the system. Output: Solaris 10: {noformat} # facter...
This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)
--
You received this message because you are subscribed to the Google Groups Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.
Jira (PUP-229) User provider password_max_age attribute is flawed under Solaris
Title: Message Title
Stefan Schulte updated an issue
Puppet / PUP-229
User provider password_max_age attribute is flawed under Solaris
Change By:
Stefan Schulte
Auserreportedthis,anddidanexcellentwriteupoftheissueandapossiblefix,soI'mjustgoingtopastethat: Thepassword_max_agelogicisflawedonSolaris.Atfirst,itseemstowork: \ {noformat} #tail-1/etc/passwd foobar:x:911:911::/home/foobar:/bin/sh \ #tail-1/etc/shadow foobar:GI2XGzW0DitJk:15931::182:28::: {noformat} ExcerptfromPuppetmanifest: {code} user{'foobar': uid=911, gid=911, password_max_age=-1, ensure=present, } \ {code}{noformat} #/opt/puppet/bin/puppetagent--test ... notice:/Stage[main]/Site::Common/User[foobar]/password_max_age:password_max_agechanged'182'to'-1' root@its-au-psnpdevap4:/export/home/e05593#tail-1/etc/shadow foobar:GI2XGzW0DitJk:15931:: {noformat} Sofarsogood...passwordexpirationwasremovedproperlyandsubsequentpuppetrunsarequiet.Theproblemoccursafterafailedloginattempt: {noformat} root@its-au-psnpdevap4:/export/home/e05593#tail-1/etc/shadow foobar:GI2XGzW0DitJk:15931::1 {noformat} Noticethelastfieldisnow {{ 1 }} indicating1failedlogin.Puppetwillnowwronglyclaimthatpasswordexpirationisenabled...andallsubsequentPuppetrunsattempttoremoveit: \ {noformat} #/opt/puppet/bin/puppetagent--test ... notice:/Stage[main]/Site::Common/User[foobar]/password_max_age:password_max_agechanged''to'-1' {noformat} Thelogicerrorisin {{ user_role_add.rb }} .Thefollowingpatchseemstofixtheproblem: pre {noformat} ---/opt/puppet/lib/ruby/site_ruby/1.8/puppet/provider/user/user_role_add.rb2013-06-0807:47:48.0+1000 +++user_role_add.rb2013-08-1416:55:46.347435848+1000 @@-174,7+174,7@@ defpassword_max_age return:absentunlessshadow_entry -shadow_entry[4]||-1 +(shadow_entry[4].nil?||shadow_entry[4].empty?)?-1:shadow_entry[4] end #Readin/etc/shadow,findthelineforourusedandrewriteitwiththe /pre {noformat} Personally,Ifinditconfusingtohavenilarrayelements,becauseshadowshouldalwayshave9fields.Iwouldprobablyhavepopulated@shadow_entryasfollows: pre {noformat} ---/opt/puppet/lib/ruby/site_ruby/1.8/puppet/provider/user/user_role_add.rb2013-06-0807:47:48.0+1000 +++user_role_add.rb2013-08-1417:01:14.141392541+1000 @@-160,7+160,7@@ return@shadow_entryifdefined?@shadow_entry @shadow_entry=File.readlines(target_file_path). reject{|r|r=~/^[^\w]/}. -collect{|l|l.chomp.split(':')}. +collect{|l|l.chomp.split(':',-1)}. find{|user,_|user==@resource[:name]} end /pre {noformat} Notethattheoriginallogicerrorwouldhavebeenobviousifthisapproachhadbeenused.Itwouldalsorender {{ .nil? }} checksunnecessary...assuminganarraylengthsanitycheckafterthefileisread.
Add Comment
Jira (FACT-155) Facter in Solaris 10 behaves differently from Solaris 11
Title: Message Title Stefan Schulte commented on an issue Re: Facter in Solaris 10 behaves differently from Solaris 11 The kernelversion seems to return the output of uname -v on Solaris which does return the output you have shown for Solaris 10 and Solaris 11. I am not sure if the output of uname -v makes a lot of sense though The kernelrelease fact can be used to reliable distinguish between Solaris 10 (5.10) and Solaris 11 (5.11) and in my opinion shows correct behaviour. About operatingsystemrelease: This one did return the same as kernelrelease in the past and was actually changed to include the update on Solaris 10 (see old feature request on redmine). Unfortunately the fact does not seem to handle Solaris 11 correctly and now falls back to return the kernelrelease fact again. This needs fixing. The old feature request indicates that the update version is a valuable information and in my opinion including major and patch version numbers is also more in line with what the fact does return on other systems like RedHat. But I'd vote to add solaris support for the operatingsystemmajrelease facts that has been added in the past (see old feature request on redmine) Add Comment Facter / FACT-155 Facter in Solaris 10 behaves differently from Solaris 11 Facter behaves differently in Solaris 10 and 11. I would expect operatingsystemrelease to be the major release of the operating system. This is how it works in Solaris 11. However not in Solaris 10. In Solaris 10 it outputs the update version which is very irrelevant depending on patch levels of the system. Output: Solaris 10: # facter operatingsy...
Jira (FACT-155) Facter in Solaris 10 behaves differently from Solaris 11
Title: Message Title
Stefan Schulte updated an issue
Facter / FACT-155
Facter in Solaris 10 behaves differently from Solaris 11
Change By:
Stefan Schulte
FacterbehavesdifferentlyinSolaris10and11.Iwouldexpectoperatingsystemreleasetobethemajorreleaseoftheoperatingsystem.ThisishowitworksinSolaris11.HowevernotinSolaris10.InSolaris10itoutputstheupdateversionwhichisveryirrelevantdependingonpatchlevelsofthesystem.Output:Solaris10: {noformat} #facteroperatingsystemreleasekernelreleasekernelversionkernelrelease=5.10kernelversion=Generic_147441-09operatingsystemrelease=10_u9#uname-aSunOSgsenorprudev0015.10Generic_147441-09i86pci386i86pc {noformat} Solaris11: {noformat} #facteroperatingsystemreleasekernelreleasekernelversionkernelrelease=5.11kernelversion=11.1operatingsystemrelease=5.11#uname-aSunOSgsenorprudev0035..1i86pci386i86pc {noformat} Thesolaris11systemisofSolaris11update1.Howevercorrectlythisdoesnotshowinthereleasefact.Thisbehaviorchangedsomewheredownthelineinfacter.Itusedtobecorrect.IfailtoseeanyuseoftheUpdateinformationforanyconfigurationanditisweirdtomethereferthistokernelreleasewhenthisisverydifferent.Itchangesalot.
Add Comment
This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)
--
You received this message because you are subscribed to the Google Groups Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.
