Well, after certain research I've finally built the Cfengine RPM with
bison. Unfortunately I've got no success, because Cfengine is
complaining upon startup:
# /etc/init.d/cfengine3 start
Starting cfengine3 ...
!! The mutex 6 was not locked in PromiseIdExists() -- status=35
Fatal cfengine error: S
Hello.
If i need some bundlesequence and inputs for all classes expect one
How can i exclude classes for example sf_* ?
Why i can't write any.!sf_*:: ?
--
Vasiliy G Tolstov
Selfip.Ru
___
Help-cfengine mailing list
Help-cfengine@cfengine.org
https:
bundle common c
{
classes:
"sf_group" expression => classmatch("sf_.*");
}
body common control
{
sf_group::
bundlesequence => { ... };
!sf_group::
bundlesequence => { ... };
}
2010/5/31 Vasiliy G Tolstov :
> Hello.
>
> If i need some bundlesequence and inputs for all classes
Now it seems like I like talking to myself ;>
Anyway, I've looked further and found that error code 35 stands for
EDEADLK which wasn't obviously meant by pthread_mutex_trylock manual
page authors, but it states for sure that the mutex is locked. So I've
patched transaction.c a bit to handle it. Th
Well,
looking further into the code I've discovered that the message is
question is being out when IP is listed in cfs_denyconnects. My big
WHY is now mode on. I never put anything into denyconnects. Doh...
2010/5/31 Seva Gluschenko :
> Now it seems like I like talking to myself ;>
>
> Anyway, I'
Finally, cute response I've got from the client:
Protocol transaction sent illegal cipher length
!! Authentication dialogue with X.X.X.X failed
Something is seriously wrong there.
2010/5/31 Seva Gluschenko :
> Well,
>
> looking further into the code I've discovered that the message is
> questio
Are you using the same version of cfengine for the client and the server ?
You compiled cfengine from the source, which version of openssh are you
using ?
On 31/05/2010 13:54, Seva Gluschenko wrote:
> Finally, cute response I've got from the client:
>
> Protocol transaction sent illegal cipher le
Sorry, patched the threading for something unrelated. Could be a conflict. Try
new svn
Seva Gluschenko wrote:
> Now it seems like I like talking to myself ;>
>
> Anyway, I've looked further and found that error code 35 stands for
> EDEADLK which wasn't obviously meant by pthread_mutex_trylock
Mark,
Just updated to rev. 1027. If you could be so kind and add EDEADLK
acknowledgment to transation.c (the patch I've sent), that would help
some Linux systems users, I believe.
At the first glance, the message is still there:
May 31 16:56:20 xxx cf-serverd[14666]: Denying connection from
non
Could be - depends what the clients were before. I am not seeing this kind of
error.
Usually it is a case of error in the policy that is difficult to see.
M
Seva Gluschenko wrote:
> Mark,
>
> Just updated to rev. 1027. If you could be so kind and add EDEADLK
> acknowledgment to transation.c (t
Mark,
both server and clients were cfengine-community-3.0.4p2-1.centos5.i386.rpm.
Now server is running cfengine-community-3.0.5-b1.i386.rpm, built from
the source. I've configured one of clients for the package update, so
will see whether it helps. It would be really helpful to have a chance
to
Then look for a configuration error. I doubt there is a problem with Cfengine
itself.
Use -v on both sides to debug
M
Seva Gluschenko wrote:
> Mark,
>
> both server and clients were cfengine-community-3.0.4p2-1.centos5.i386.rpm.
>
> Now server is running cfengine-community-3.0.5-b1.i386.rpm,
To further clarify what Seva said (which is 100% correct :-), you don't need
to say "any.!foo" - if you say "!foo" it means "not foo" which includes
"anything else" :-)
-Dan
> bundle common c
> {
> classes:
> "sf_group" expression => classmatch("sf_.*");
> }
>
> body common control
> {
>
Mark,
there are no configuration errors. cf-promises -v reports "Inputs are
valid". Nicolas in private conversation told me that there were loads
of "Denying connection from non-authorized IP" on the 3.0.4 due to an
issue with the cryptographic part.
Actually, after installing 3.0.5b1 on the poli
I complete : there were load of this error on my servers (this doesn't
seem so common since not so many people complained about it, and it was
quite hard to debug)
On 31/05/2010 17:24, Seva Gluschenko wrote:
> Mark,
>
> there are no configuration errors. cf-promises -v reports "Inputs are
> vali
Perhaps, I forgot to mention, but obvious problems arose after
increasing number of managed servers to 200+. There were no problems
when it was only 20 of them.
2010/5/31 Nicolas Charles :
> I complete : there were load of this error on my servers (this doesn't
> seem so common since not so many p
Can you provide the output of an exact session that is failing, including the
error
message from both sides.
./cf-serverd -v
./cf.agent -v (cut the relevant parts)
M
Seva Gluschenko wrote:
> Perhaps, I forgot to mention, but obvious problems arose after
> increasing number of managed servers
Mark,
while I didn't succeed yet to obtain a piece of verbose output from a
client (just because I didn't want to flood all the clients with that
and tried to take it from one client only), I've got smth interesting
from the server:
cf3 Loaded /var/cfengine/ppkeys/root-192.168.5.1.pub
cf3 Loaded
18 matches
Mail list logo
