** Patch added: output of diff -u krb5.aug.old
/usr/share/augeas/lenses/dist/krb5.aug
https://bugs.launchpad.net/ubuntu/+source/augeas/+bug/1302638/+attachment/4065670/+files/krb5.aug.patch
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is
Public bug reported:
In Trusty, augtool doesn't parse the default /etc/krb5.conf
There are multiple issues. The lens cannot handle some keywords, it cannot
handle heading digits in realm names, and it cannot handle lowercase realms in
the [realms] section. After the following patch, it can, and
I'm the one who should do the thanking: I'm using your distro.
I have not sent the changes upstream.
I'm not very familiar with the jargon of parse tree structure. I'd say it
obviously causes changes in the structure of the tree: it adds leaves. But I
presume the question is meant: Are there
Ok, I cloned the GitHub repository, forked, making changes.
As for unit tests, it looks to me like an entire lens is the unit of testing,
so I would edit lenses/tests/test_krb5.aug to include some previously unparsed
in- and output. Is that what you want me to do?
Also, it's not unlikely that
I opened a PR on Github as Raphaƫl requested.
One more thing: the Trusty source package depends neither on flex nor on
bison. I think it should, but I'm not sure enough to open another bug.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed
Err.. s/depends/build-depends/
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to augeas in Ubuntu.
https://bugs.launchpad.net/bugs/1302638
Title:
augeas-tools fails to parse krb5.conf (solution provided)
To manage notifications about
Public bug reported:
Abstract:
Puppet initscript doesn't record the correct PID. WIth this patch, it does.
Longer version:
When the Puppet agent daemon gets started, /etc/init.d/puppet records a PID in
/var/run/puppet/${NAME}.pid, but it is the wrong one. Puppet may fork half a
dozen times
Public bug reported:
Abstract:
When the Puppet agent daemon is unable to get a certificate, it dies on
receiving SIGUSR1.
Longer version:
Right after boot, the Puppet agent daemon is started. It may be running before
hostname resolution is available. If it is, Puppet is unable to receive a
Version data:
Ubuntu Trusty
Puppet 3.4.3-1 0
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to puppet in Ubuntu.
https://bugs.launchpad.net/bugs/1397898
Title:
incorrect PID in initscript
To manage notifications about this bug go to:
On 12/01/2014 06:49 PM, Robie Basak wrote:
Then isn't something else broken that causes puppet to be started before
hostname resolution is available? What is on your system that causes
hostname resolution to not be available? Can we fix that instead?
Perhaps we can. Puppet runs from a SystemV
It should go to Debian in the first instance, assuming that Debian is
Ok. Then it'll have to wait until I can confirm that Debian is affected
as well.
Thanks!
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to puppet in Ubuntu.
On 12/01/2014 07:31 PM, Robie Basak wrote:
What is it trying to look up? Itself, or something else? I'd expect a
self-lookup to always succeed.
It tries to look up the Puppet server, to fetch a certificate from.
Maybe it also tries to look up itself. But that would succeed, indeed.
If for some
On 12/01/2014 10:42 PM, Stig Sandbeck Mathisen wrote:
That's a delightfully evil hack. Will using an upstart job work instead,
or do you need to keep track of the PID there, as well (something for
post-start, then)?
Matthaus Owens of Puppet Labs responded that Puppet *does* write its own
PID.
On 12/02/2014 12:21 AM, Matthaus Owens wrote:
Sorry, I should have said pidfile is written to $rundir/agent.pid.
$rundir defaults to $vardir/run if not specified in puppet.conf.
Thank you! Now my config works, and this 'bug' report should never have
existed. :)
--
You received this bug
14 matches
Mail list logo