Am 04.04.2016 um 09:06 schrieb Martin Babinsky:
> On 04/01/2016 08:53 PM, Martin (Lists) wrote:
>> Hallo
>>
>> I have a question regarding enabling/disabling separate ipa parts in
>> systemd. Is it necessarry or required to have httpd, directory server,
>> nam
Hallo
I have a question regarding enabling/disabling separate ipa parts in
systemd. Is it necessarry or required to have httpd, directory server,
named memcache and all the other ipa services to be enabled in systemd?
Or is it recomended to have only the main ipa service enabled (and all
the other
Am 09.11.2015 um 19:38 schrieb Martin (Lists):
> Hallo
>
> recently I tried to add a user to one of my groups, but this always
> failed with the error message: This entry already exists.
>
> Of course does this entry (user) exists, but not in this group. and it
> is not added
Hallo
recently I tried to add a user to one of my groups, but this always
failed with the error message: This entry already exists.
Of course does this entry (user) exists, but not in this group. and it
is not added. I tried to add this from web interface and command line
with the same result.
I
Am Freitag, 1. Mai 2015, 21:21:09 schrieb Martin:
> Sorry, first post went to Ludwig only. Now to the list as well.
>
> Am 30.04.2015 um 13:36 schrieb Ludwig Krispenz:
> >>> indicating that trimming works.
> >>
> >> As it seems my trimming is broken, at least partially. Is there
> >> something I
Sorry, first post went to Ludwig only. Now to the list as well.
Am 30.04.2015 um 13:36 schrieb Ludwig Krispenz:
>>> indicating that trimming works.
>> As it seems my trimming is broken, at least partially. Is there
>> something I can adjust?
> no, it seems to be ok, IPA configures the "changelog m
Am 29.04.2015 um 15:43 schrieb Ludwig Krispenz:
>
> On 04/29/2015 03:17 PM, Martin (Lists) wrote:
>> Am 27.04.2015 um 09:45 schrieb Ludwig Krispenz:
>>> On 04/26/2015 10:49 AM, Martin (Lists) wrote:
>>>> Hallo
>>>>
>>>> after
Am 27.04.2015 um 09:45 schrieb Ludwig Krispenz:
>
> On 04/26/2015 10:49 AM, Martin (Lists) wrote:
> > Hallo
> >
> > after a reboot I get almost thousand of the following messages:
> >
> > DSRetroclPlugin - delete_changerecord: could not delete change record
>
Hallo
after a reboot I get almost thousand of the following messages:
DSRetroclPlugin - delete_changerecord: could not delete change record
128755 (rc: 32)
The record number changes from 127600 up to 148400. What does this mean?
I have searched the web but did not find any hint on this.
I use F
Am 08.04.2015 um 10:57 schrieb Jakub Hrozek:
>
> >
> >
> > Most of the host can only communicate in the local net, which has not
> > that much hosts (10). The wired ones are connected via GBit Network,
> > wireless it is up to 150MBit. Server is a Xeon E3-1225 with 8GB Mem. All
> > Systems have F
Am 08.04.2015 um 10:27 schrieb Jakub Hrozek:
> Can you run:
> KRB5_TRACE=/dev/stderr kinit yourprinc@YOUR.REALM
>
> So that we can compare with the krb5_child.log you sent earlier? I
> wonder if SSSD talks to a KDC that is slower or far away from your
> client..
>
This is my trace from kinit:
Am 07.04.2015 um 18:27 schrieb Simo Sorce:
> On Tue, 2015-04-07 at 17:57 +0200, Martin (Lists) wrote:
>> Hallo
>>
>> attached you can find the data from krb_child.log. As far as I can see
>> it, the three seconds are due to the communication with the kerberos
>&
Hallo
attached you can find the data from krb_child.log. As far as I can see
it, the three seconds are due to the communication with the kerberos
server. (1.2.3.4 is my server).
regards
Martin
Am 07.04.2015 um 11:21 schrieb Jakub Hrozek:
> On Tue, Apr 07, 2015 at 11:12:40AM +0200, Martin (Li
Am 05.04.2015 um 11:51 schrieb Martin (Lists):
>
> Hallo
>
> I have a similar issue. On login (graphic systems and ssh) and on the
> screen saver I have a delay from about 2 secons to 10 seconds.
>
> According to my logfile i have the following timeline at login:
>
>
Am 05.04.2015 um 06:10 schrieb Dan Mossor:
> I've recently deployed a new domain based on 4.1.2 in F21. We've noticed
> an issue and can't quite seem to nail it down. The problem is that
> logins are taking an inordinate amount of time to complete - the fastest
> logon we can get using LDAP credent
15 matches
Mail list logo
