Since it was developed in parallel, they used
https://github.com/puppetlabs/facter-ng. I don't know if there are plans to
reconcile them in the future, but Bogdan could tell you about that later.
On Mon, Mar 30, 2020 at 2:38 PM Stefan Wrobel wrote:
> Where is the source for the 4.x releases?
> h
Hi Adam,
The related code in Facter is at
https://github.com/puppetlabs/facter/blob/master/lib/src/facts/external/json_resolver.cc#L211-L214
It appears that the JSON library we use (RapidJSON) considers an empty file
to be an error condition, and we just raise that up without introspecting
it. Th
I guess if the answer had been more of a puppet answer, my question would
have been more of a puppet question. :-)
Sorry to bother.
Thanks,
Guy
On Wed, Dec 24, 2014 at 12:42 PM, Craig White wrote:
> Not really a puppet question or a puppet answer
>
> man alias (bash command)
>
> You should be
Hi All,
yes same with me. I restarted the system and errors are gone.
Still was not able to find the root cause.
I m good for now after the restart.
With Warm Regards
Kaustubh.A.Chaudhari
(M)-09373102619
On Wed, Oct 1, 2014 at 3:21 PM, jmp242 wrote:
> Ok, thanks, it turns out restarting the
On Wed, Oct 1, 2014 at 10:05 AM, Wil Cooley wrote:
> On Wed, Oct 1, 2014 at 9:48 AM, jmp242 wrote:
>
>> I also see this on 3.7.1... Same symptoms.
>>
>
>> On Wednesday, September 24, 2014 8:16:54 AM UTC-4, JonY wrote:
>>>
>>> I'm seeing this error appear on a client machine (/var/log/syslog):
>>
On Wed, Oct 1, 2014 at 9:48 AM, jmp242 wrote:
> I also see this on 3.7.1... Same symptoms.
>
> On Wednesday, September 24, 2014 8:16:54 AM UTC-4, JonY wrote:
>>
>> I'm seeing this error appear on a client machine (/var/log/syslog):
>>
>> puppet-agent[17158]: Failed to apply catalog: Could not r
I don't know where that "Invalid facter option(s)" exception is coming
from. Can you run with trace=true?
Thanks!
On Fri, Sep 26, 2014 at 3:02 AM, kaustubh chaudhari
wrote:
>
> Hi,
>
> I am also facing same issue. unable to find where to look for, puppet
> agent runes file facter runes fine if
Hi,
I was on 1.7 now upgraded to 2.2.
With Warm Regards
Kaustubh.A.Chaudhari
(M)-09373102619
On Sat, Sep 27, 2014 at 1:43 PM, Jason Antman wrote:
> What facter versions are you running?
>
> On Fri, Sep 26, 2014 at 6:02 AM, kaustubh chaudhari
> wrote:
>
>>
>> Hi,
>>
>> I am also facing same
What facter versions are you running?
On Fri, Sep 26, 2014 at 6:02 AM, kaustubh chaudhari
wrote:
>
> Hi,
>
> I am also facing same issue. unable to find where to look for, puppet
> agent runes file facter runes fine if run manually.
>
>
> But schedule run still not working.
>
> Any help is appre
Em 28/07/14 16:34, Robin Bowes escreveu:
Hmm, I find that hard to believe, ie. that's a pretty massive and
fundamental bug in facter if that is indeed the case.
Perhaps I have a not-so-common use case? I'm manually running (local
rundeck) puppet agent in my tests via ssh. Ssh was sending my l
Hmm, I find that hard to believe, ie. that's a pretty massive and
fundamental bug in facter if that is indeed the case.
Can you reproduce on other boxes?
R.
On 28 July 2014 19:19, Joao Morais wrote:
>
> List, just to document the solution. My CentOS was localized and facter
> couldn't parse d
You are confusing custom and external facts, as david explained.
Regards,
El 22/07/2014 18:33, "Maxim Nikolaev" escribió:
> As I understand from Facrer 2 manual (
> http://docs.puppetlabs.com/facter/2.1/custom_facts.html#adding-custom-facts-to-facter)
> I can set all custom facts to /etc/facts/
Dear Maxim,
/etc/facter/facts.d and /usr/lib/ruby/site_ruby/1.8/facter/ are used for
two completely different kinds of scripts that cannot be mixed.
/etc/facter/facts.d contains either text files with *static* facts OR
executable *programs* returning a specific text format.
/usr/lib/ruby/si
On Fri, Jul 18, 2014 at 11:56 AM, Jim Richard wrote:
> Yep, a custom fact. In case someone else happens upon this looking for a
> similar answer, here's my custom fact to override Facter's default path
> fact:
>
> Facter.add('path') do
> confine :kernel => 'windows'
> setcode do
>my_fact
Hello,
I came looking for this exact error, but specifying "--server
puppetmaster.domain" or setting "server = puppetmaster.domain" in
puppet.conf doesn't allow a successful run of puppet. The error is the same
as Paul had above:
Error: Could not request certificate: SSL_connect returned=1 err
>
> Paul, that ssl error looks like the following post on puppet-users:
> https://groups.google.com/forum/#!topic/puppet-users/4-6EimF_-NY/discussion,
> which relates to SNI.
>
Thank you for pointing me in the right direction.
> Adding a server alias to your puppetmaster vhost may resolve yo
Paul, that ssl error looks like the following post on puppet-users:
https://groups.google.com/forum/#!topic/puppet-users/4-6EimF_-NY/discussion,
which relates to SNI. Adding a server alias to your puppetmaster vhost may
resolve your problem. This is a change in ruby after 1.9.0, so it wouldn't
have
> facter-1.7.4-rc1 is available and it looks like it works!
Actually, it wasn't until 1.7.5 that the packages available from
downloads.puppetlabs.com were fixed, but it really seems to work now.
However, I have a problem with puppet on OS X 10.9. I'm using the
latest packaged version 3.4.2.
It m
Sure ...
Here it is:
#
# terracota_version.rb
#
# Reports terracota version if terracotta is installed
Facter.add(:terracotta_version) do
cmd = %x{/bin/rpm -qa terracotta --queryformat %{VERSION}}
setcode do
if ! cmd.nil?
cmd
else
nil
end
end
end
-frederiko
On Fri, Sep 20, 2013 at 10:
Hi Ellison, thank you for help, theres some bug i think in that version,
now i use 1.6.18-3.el6 its solved.
On Wed, May 22, 2013 at 11:49 PM, Ellison Marks wrote:
> I'm on 1.7.1, Facter finds xen fine.
>
> is_virtual => true
> virtual => xen
>
> odd part is I'm not sure the detection method has
Thanks for responding, John, and for your thoughts.
That makes sense. I think I will start a thread on the developer's list about
this.
“Sometimes I think the surest sign that intelligent life exists elsewhere in
the universe is that none of it has tried to contact us.”
Bill Waterson (Calvi
I have upgraded my facter version :
facter --version
1.6.9
It's now working like a charm
Thx.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/4729ePmYnU4
*facter --version*
*1.5.7*
2012/11/28 Matthaus Owens
> Which facter version are you seeing this on? (`facter --version`)
>
> On Wed, Nov 28, 2012 at 9:14 AM, AnOnJoe wrote:
> > sorry there is a typo :
> >
> > Le mercredi 28 novembre 2012 18:06:54 UTC+1, AnOnJoe a écrit :
> >>
> >> Hello,
> >>
Haven"t read the code yet...
But cmd facter xx executes the xx plugin and print the return value. the
ipaddress_ethX are part of the ipaddress plugin that is the one that should
be executed. Nonetheless as the ipaddress plugin register the
ipaddress_ethX facters they would not show either.
On Wed
Which facter version are you seeing this on? (`facter --version`)
On Wed, Nov 28, 2012 at 9:14 AM, AnOnJoe wrote:
> sorry there is a typo :
>
> Le mercredi 28 novembre 2012 18:06:54 UTC+1, AnOnJoe a écrit :
>>
>> Hello,
>> I have a problem with facter :
>>
>> eg:
>>>
>>> facter |grep ipaddress_et
On Thu, Sep 6, 2012 at 1:01 AM, Axel Bock wrote:
> I have no idea what my init scripts are doing actually :) . I am just
> wondering why nothing shows up when *I* run puppet agent --test.
> And it still confuses me that this seems to be a requirement (which I could
> not find anywhere ... not that
I have no idea what my init scripts are doing actually :) . I am just
wondering why nothing shows up when *I* run puppet agent --test.
And it still confuses me that this seems to be a requirement (which I could
not find anywhere ... not that I looked, though :) for a command line tool
which usua
Hi,
Why do your init scripts start puppet with a locale other than C?
Cheers,
--
Stephen Gran
Senior Systems Integrator - guardian.co.uk
Please consider the environment before printing this email.
--
Visit guardian.co.uk - newspape
I am going to guess this is the old 'There's no /sbin/ifconfig' thing.
I've got a pull request for facter that fixes this and a bunch of
other stuff at https://github.com/puppetlabs/facter/pull/267 if you
want to try checking out that version of Facter and trying it on your
SuSE box. It'll try an
Hi,
sounds like it could be a similar issue of puppet with mongrel. This was raised
recently on the list. Have a look at those.
Also paste the code you are trying to apply so we can see what you're
attempting to do.
Here is a link that you can use to see some tips on debugging issues.
http://
> Thanks for your help. Unfortunately, I can't tell you much about the
> setup. I've only ever done this with passenger as well, and the person
> who did set it up has
> left the company.
I'm not really sure if you should raise a new ticket on this one - or
add an addendum to this:
http://project
On Tue, Sep 13, 2011 at 5:16 PM, Douglas Garstang
wrote:
>
> I wonder if the performance of the puppet master in 2.7.3 has
> increased to the point where passenger/mongrel aren't really required
> anymore? I'm running puppet in standalone debug right now, and forced
> 40 or so clients to reconnect
On Tue, Sep 13, 2011 at 5:12 PM, Ken Barber wrote:
>> I think this may be totally related. We're using mongrel... AND,
>> running the puppet master in standalone mode as you suggested yields
>> this now on the client:
>>
>> Sep 13 16:49:06 hproxy11 puppet-agent[27311]:
>> (/Stage[main]/Puppet::Set
> I think this may be totally related. We're using mongrel... AND,
> running the puppet master in standalone mode as you suggested yields
> this now on the client:
>
> Sep 13 16:49:06 hproxy11 puppet-agent[27311]:
> (/Stage[main]/Puppet::Setup/Notify[xxx = 2.7.3 ...]/message) defined
> 'message' as
On Tue, Sep 13, 2011 at 4:43 PM, Ken Barber wrote:
> How are you running your puppet master?
>
> Can you try it with just:
>
> puppet master --debug --no-daemonize
>
> Just there was a thread I recall about Mongrel - it may not be related:
>
> http://groups.google.com/group/puppet-users/browse_thr
How are you running your puppet master?
Can you try it with just:
puppet master --debug --no-daemonize
Just there was a thread I recall about Mongrel - it may not be related:
http://groups.google.com/group/puppet-users/browse_thread/thread/3f4072d375851ee7
It would be nice to see a packet capt
On Tue, Sep 13, 2011 at 4:27 PM, Ken Barber wrote:
> You could always do one of your crazy greps :-).
:(
>
> Out of curiosity - what do your /var/lib/puppet/yaml/facts/*.yaml
> files show you on your server?
clientversion: &id001 0.25.5
:(
Doug
--
You received this message because you are s
You could always do one of your crazy greps :-).
Out of curiosity - what do your /var/lib/puppet/yaml/facts/*.yaml
files show you on your server?
ken.
On Wed, Sep 14, 2011 at 12:16 AM, Douglas Garstang
wrote:
> On Tue, Sep 13, 2011 at 4:01 PM, Douglas Garstang
> wrote:
>> On Tue, Sep 13, 2011
On Tue, Sep 13, 2011 at 4:01 PM, Douglas Garstang
wrote:
> On Tue, Sep 13, 2011 at 3:21 PM, Douglas Garstang
> wrote:
>> On Tue, Sep 13, 2011 at 1:06 PM, Ken Barber wrote:
>>> Hmm ... well can you try using ${::puppetversion} ...?
>>
>> Adding this:
>>
>> notify{"xxx = ${::puppetversion} ...":}
On Tue, Sep 13, 2011 at 3:21 PM, Douglas Garstang
wrote:
> On Tue, Sep 13, 2011 at 1:06 PM, Ken Barber wrote:
>> Hmm ... well can you try using ${::puppetversion} ...?
>
> Adding this:
>
> notify{"xxx = ${::puppetversion} ...":}
>
> to the manifest gives this on the server:
>
> Sep 13 15:14:43 sv
On Tue, Sep 13, 2011 at 1:06 PM, Ken Barber wrote:
> Hmm ... well can you try using ${::puppetversion} ...?
Adding this:
notify{"xxx = ${::puppetversion} ...":}
to the manifest gives this on the server:
Sep 13 15:14:43 sv2admin1 puppet-master[22452]:
(//hproxy11.h.foo.com//Stage[main]/Puppet::
Good to hear. That fix should be in the next rc.
ken.
On Tue, Sep 13, 2011 at 10:46 PM, Sans wrote:
> Done!!
> Work like a charm. thanks.
>
> -Santanu
>
>
> On Sep 13, 9:25 pm, Ken Barber wrote:
>> Yeah - try this copy instead if you can:
>>
>> https://raw.github.com/puppetlabs/facter/master/li
Yeah - try this copy instead if you can:
https://raw.github.com/puppetlabs/facter/master/lib/facter/domain.rb
ken.
On Tue, Sep 13, 2011 at 9:21 PM, Sans wrote:
> Thanks Ken!
> Back home an hr. or so ago and saw you reply. Is it the "/usr/lib/ruby/
> site_ruby/1.8/facter/domain.rb" file that you
Hmm ... well can you try using ${::puppetversion} ...?
Also - I notice you are using an ENC ... can you disable that and just
use node entries? Yet another place where we might be getting vars we
don't expect. In fact - setup a site.pp that is really blank - and
only contains that notify statement
On Tue, Sep 13, 2011 at 12:46 PM, Ken Barber wrote:
> The reason why I say this - is because I can replicate this problem myself
> with:
>
> node default {
> $puppetversion = "0.25.5"
> notice($puppetversion)
> }
>
> In fact its the only way I can think of to replicate the issue -
> besides all
Even using:
notify{"${::puppetversion} on ${::fqdn}":}
Instead would be of interest ...
ken.
On Tue, Sep 13, 2011 at 8:46 PM, Ken Barber wrote:
> The reason why I say this - is because I can replicate this problem myself
> with:
>
> node default {
> $puppetversion = "0.25.5"
> notice($puppe
The reason why I say this - is because I can replicate this problem myself with:
node default {
$puppetversion = "0.25.5"
notice($puppetversion)
}
In fact its the only way I can think of to replicate the issue -
besides all the other ways we have already ruled out. *shrug*.
ken.
On Tue, Sep
On Sep 13, 2011, at 12:28 PM, Douglas Garstang wrote:
> On Tue, Sep 13, 2011 at 12:25 PM, Craig White wrote:
>>
>> I'm thinking that he has puppet 0.25.5 gem installed and all of the rpm -e /
>> yum remove isn't going to solve that.
>>
>> try 'gem list --local'
>
> Craig, I posted this yeste
So that is the only case where you are using the variable throughout
your entire code? I mean - ALL your code ... not just the one line you
are printing to the screen ...
ken.
On Tue, Sep 13, 2011 at 8:30 PM, Douglas Garstang
wrote:
> On Tue, Sep 13, 2011 at 11:01 AM, Ken Barber wrote:
>> Yeah
On Tue, Sep 13, 2011 at 11:01 AM, Ken Barber wrote:
> Yeah this doesn't seem to be old versions of Puppet.
>
> So from my other email ... can you show us the code where you are
> doing your comparison for $puppetversion? I have a feeling I might
> know what it is ... although I'm probably wrong ..
On Tue, Sep 13, 2011 at 12:25 PM, Craig White wrote:
>
> On Sep 13, 2011, at 10:48 AM, Douglas Garstang wrote:
>
>> On Tue, Sep 13, 2011 at 10:46 AM, R.I.Pienaar wrote:
>>>
>>>
>>> - Original Message -
On Tue, Sep 13, 2011 at 1:45 AM, Luke Bigum
wrote:
> Err, what is that 0
On Sep 13, 2011, at 10:48 AM, Douglas Garstang wrote:
> On Tue, Sep 13, 2011 at 10:46 AM, R.I.Pienaar wrote:
>>
>>
>> - Original Message -
>>> On Tue, Sep 13, 2011 at 1:45 AM, Luke Bigum
>>> wrote:
Err, what is that 0.25-5 doc folder and what RPM owns it?
rpm -qf /usr/
If that were true the job of QA would be much easier
On Sep 13, 2011 10:48 AM, "Douglas Garstang"
wrote:
> On Tue, Sep 13, 2011 at 10:46 AM, R.I.Pienaar wrote:
>>
>>
>> - Original Message -
>>> On Tue, Sep 13, 2011 at 1:45 AM, Luke Bigum
>>> wrote:
>>> > Err, what is that 0.25-5 doc fol
Yeah this doesn't seem to be old versions of Puppet.
So from my other email ... can you show us the code where you are
doing your comparison for $puppetversion? I have a feeling I might
know what it is ... although I'm probably wrong ...
In fact - grep for 'puppetversion' in all of your puppet co
On Tue, Sep 13, 2011 at 10:46 AM, R.I.Pienaar wrote:
>
>
> - Original Message -
>> On Tue, Sep 13, 2011 at 1:45 AM, Luke Bigum
>> wrote:
>> > Err, what is that 0.25-5 doc folder and what RPM owns it?
>> >
>> > rpm -qf /usr/share/doc/puppet-0.25.5
>> >
>> > If nothing owns it, you've prett
- Original Message -
> On Tue, Sep 13, 2011 at 1:45 AM, Luke Bigum
> wrote:
> > Err, what is that 0.25-5 doc folder and what RPM owns it?
> >
> > rpm -qf /usr/share/doc/puppet-0.25.5
> >
> > If nothing owns it, you've pretty much proved your system has old
> > Puppet artefacts lying arou
On Tue, Sep 13, 2011 at 1:45 AM, Luke Bigum wrote:
> Err, what is that 0.25-5 doc folder and what RPM owns it?
>
> rpm -qf /usr/share/doc/puppet-0.25.5
>
> If nothing owns it, you've pretty much proved your system has old
> Puppet artefacts lying around. Personally I wouldn't trust any of the
> co
Since this is urgent and we are in RC, I've raised a bug for you Sans:
http://projects.puppetlabs.com/issues/9457
ken.
On Tue, Sep 13, 2011 at 3:43 PM, Ken Barber wrote:
> Yeah okay I was close though :-).
>
> if name = Facter::Util::Resolution.exec('hostname')
> ...
> elsif domain
Yeah okay I was close though :-).
if name = Facter::Util::Resolution.exec('hostname')
...
elsif domain = Facter::Util::Resolution.exec('dnsdomainname')
The first bit will pretty much always be true ... and if your
'hostname' command doesn't contain your full domain - it won't fall
I could be wrong about the cause actually ... I think its still a bug
though :-).
Let me take a closer look at the code and see if I can work it out.
ken.
On Tue, Sep 13, 2011 at 3:29 PM, Ken Barber wrote:
> Yep - that looks like a bug. The change was here:
>
> https://github.com/puppetlabs/fac
Yep - that looks like a bug. The change was here:
https://github.com/puppetlabs/facter/commit/f7daae300d5c993052dd6c49b1b5e1f3501eaa10
Basically the domain =~ part is _not_ returning true even though
dnsdomainname is returning something, and not falling through as it
used to to find the answer fr
On Tue, Aug 23, 2011 at 4:18 PM, Avi Miller wrote:
> I've added an issue for this on the Puppet Labs site[1] and submitted
> a patch via GitHub to determine OracleLinux properly from 5 Update 6
> and 6. This adds "OracleLinux" as an operatingsystem.
Should we still use OEL? If we change the the v
Kit,
What puppet/facter versions, which OS and what VM? Also, what is the content
of your fstab?
On Mon, Aug 22, 2011 at 12:59 PM, Kit Plummer wrote:
> Am I the only one seeing this? Permissions, or OS thing?
>
> On Aug 18, 8:14 pm, Kit Plummer wrote:
> > Hey.
> >
> > I'm using Facter to publi
On 18 August 2011 18:38, Jake wrote:
> Excellent, thanks - patch applied here with good results.
>
> It appears the issue is already known as of facter-1.5.9:
> http://projects.puppetlabs.com/issues/7957
>
> So, the ball should already be rolling on this one - right?
>
I missed that in my brief
I just tested this on a VM, and it ran fine. What platform is the server
you're ssh-ing to?
On Thu, Jun 23, 2011 at 2:51 PM, josbal wrote:
> No one has seen this issue before?
>
> On Jun 23, 3:08 pm, josbal wrote:
> > Hi Guys,
> >
> > Not sure if this issue is a facter one or not, but thought i
What version of facter? I'm not producing the error from 1.5.0 through
1.5.9 (did not have to pass -t).
Thanks,
Nan
On Thu, Jun 23, 2011 at 8:03 PM, Nathan Clemons wrote:
> Sounds like a bug with facter handling headless running where a TTY is not
> allocated (thus the error about $TERM not bei
Sounds like a bug with facter handling headless running where a TTY is not
allocated (thus the error about $TERM not being set).
--
Nathan Clemons
http://www.livemocha.com
The worlds largest online language learning community
On Thu, Jun 23, 2011 at 7:56 PM, josbal wrote:
> Hi Den,
>
> ssh -t
Hi,
Haven't tested but what does ssh -t server2 give you?
Cheers
Den
On 24/06/2011, at 7:51, josbal wrote:
> No one has seen this issue before?
>
> On Jun 23, 3:08 pm, josbal wrote:
>> Hi Guys,
>>
>> Not sure if this issue is a facter one or not, but thought i might
>> post here to see
On Sat, Nov 20, 2010 at 11:01 PM, Jay Adkisson wrote:
> FWIW, it's probably better performance-wise to do the string manipulations
> in Ruby rather than shelling out to bash.
>
> Facter.add "lokatie" do
> setcode do
> case Facter.value(:ipaddress).split('.')[1]
> when '84': 'AAA'
>
FWIW, it's probably better performance-wise to do the string manipulations
in Ruby rather than shelling out to bash.
Facter.add "lokatie" do
setcode do
case Facter.value(:ipaddress).split('.')[1]
when '84': 'AAA'
when '85': 'BBB'
# ...
else
# ...
end
end
end
Peac
On 4 June 2010 16:10, CraftyTech wrote:
> patch orig.file patch.file --- that was easy
>
There is an open bug for 1.9.x support for Facter. Can you verify this
on git master?
Paul
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to
On Fri, Jan 22, 2010 at 11:28 AM, Mark Plaksin wrote:
> Nigel Kersten writes:
>
> > On Fri, Jan 22, 2010 at 11:18 AM, Allan Marcus wrote:
> >
> >> int he example below I run facter looking for the fact
> "sp_serial_number".
> >> as you can see, the command facter sp_serial_number returns nothin
> Hmm, I'm not really a fan of such a return type thing. My proposal would
> be to have the old behavior (return a string) and then if somebody
> really rather likes an array in different places, they could write a
> wrapper method which would split the string for them.
+1
Well I think eventually
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>> Ok, some more data from git history:
>> http://github.com/reductivelabs/facter/commit/33fb7709404e706801683e6c47ab7a0a5a1884b1
>
>> It looks like "return an array" is new behavior for exec, and maybe it
>> wasn't backported/tested for all of the ol
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michael DeHaan wrote:
> Ok, some more data from git history:
> http://github.com/reductivelabs/facter/commit/33fb7709404e706801683e6c47ab7a0a5a1884b1
>
> It looks like "return an array" is new behavior for exec, and maybe it
> wasn't backported/tested
> > Though something is perhaps not kosher with it and lsb_release
> > although it works fine for me...
>
> The issue seems to be that Facter::Util::Resolution::exec is returning
> an array, not a string.
> My version of Ruby doesn't seem to want to do pattern matches against
> arrays, it seems, t
> It's set in lsb.rb.
Thanks.
>
> Though something is perhaps not kosher with it and lsb_release
> although it works fine for me...
>
The issue seems to be that Facter::Util::Resolution::exec is returning
an array, not a string.
My version of Ruby doesn't seem to want to do pattern matches again
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michael DeHaan wrote:
> I found this post from Nov 20 regarding a bug in facter. James
> Turnbull was asking then for debug output, which I've provided a bit
> later.
>
> The real trick though is this:
>
> [mdeh...@eng-dhcp-105 facter]$ ack lsbdist
I posted a question about the lsb prefixed facts a few weeks ago.
lsbmaj may be what you're looking for.
On Tue, Dec 22, 2009 at 9:17 AM, Kenton Brede wrote:
> On Tue, Oct 20, 2009 at 8:45 PM, Ohad Levy wrote:
> > Hi,
> >
> > I for one, thinks that the operatingsystemrelease fact should con
On Tue, Oct 20, 2009 at 8:45 PM, Ohad Levy wrote:
> Hi,
>
> I for one, thinks that the operatingsystemrelease fact should contain only
> the major number of the operating system, e.g. for Centos/Rehat 5.4 it
> should return just 5.
>
> the reason behind it is that I rarely use the full release ver
80 matches
Mail list logo
