I guess you didn't like redmine, gitlab, mattermost, the Atlassian
stack, or some others out there :)?
It looks neat.
So the question is why this and not anything else :)?
Maybe not the question you expected, but I am just curious.
Greetings,
Vincent
On Wed, Jan 18, 2017 at 3:56 PM, Mark
anks for the link! It's much appreciated. I'm afraid my PHP skills
> leave a lot to be desired did I mention I
> hate PHP? ;-)
>
>
>
> On 2/23/16 1:14 AM, Vincent Gerris wrote:
>
> Hi,
>
> Here is a script I used with 389 that worked fine for me a while back:
&
Hi,
Here is a script I used with 389 that worked fine for me a while back:
http://ltb-project.org/wiki/documentation/self-service-password
Greetings,
Vincent
On Tue, Feb 23, 2016 at 2:25 AM, William Brown wrote:
> Ignore the blank message. Email fail.
>
> On Mon,
there is also one here:
https://github.com/rs-services/cookbooks_internal/tree/master/cookbooks/DS389
I modified one of them to completely setup and install 389-DS in a
clustered setup, but can't find the recipe :).
I will post it if I find it.
Good luck!
On Thu, Mar 19, 2015 at 10:02 PM, David
Replication of accounts is always a challenge :).
What I have seen being used is the Retro changelog mechanism.
A script will poll for changes and keep track of what has been processed
and synced to the other side.
Where are the accounts originally created?
I get the idea the source is your Oracle
there is a windows installer included? Or you can use X for windows and
connect to the admin server with an X forward and start it.
check:
http://www.straightrunning.com/XmingNotes/
or for a nice ssh with intgrted X :
http://mobaxterm.mobatek.net/
good luck
On Thu, Aug 7, 2014 at 5:55 PM,
If you mean that the layout is messed up, you are right.
It is terrible and looks different on about any browser.
I filed a bug for the ubuntu package where I found it too:
https://bugs.launchpad.net/ubuntu/+source/389-dsgw/+bug/1286035
There has been no reaction yet, it actually should have been
Thank you for help and your work! I might send a mail to this list again
when the time comes and I need some guidance :).
On Mon, Jul 7, 2014 at 5:31 PM, Rich Megginson rmegg...@redhat.com wrote:
On 07/07/2014 08:37 AM, Vincent Gerris wrote:
I would love to patch it, but like I tried
then please share how you fixed it or what the issue was, so other people
that encounter this can solve it.
There is not much more frustrating then thinking you find a solution, only
to read someone fixed it.
thank you
On Fri, Jun 6, 2014 at 6:25 PM, g.fer.or...@unicyber.co.uk wrote:
Hi
Well I just like to note that you SHOULD NOT want to use a password like
that.
It's completely insecure and thus a very BAD idea from a security
perspective.
As far as I know, you can override a directory wide password policy per
account, so if the restrictions come from there, just change them
well it is mounted on the WAN so it is accessible there right?
NFS is by the way not the best way for a secure file share.
But what has this to do with 389?
Seems like a general networking question to me and it depends mostly on
what is done in terms of firewalling.
On Wed, Mar 26, 2014 at
and boom, looks like it works now.
On 03/17/2014 04:08 PM, Vincent Gerris wrote:
yes, I did before.
You need to copy some legacy schema stuff, for the rest it is pretty
straight forward.
Just make an ldif dump, setup the new directory server and try an import.
You will encounter any
yes, I did before.
You need to copy some legacy schema stuff, for the rest it is pretty
straight forward.
Just make an ldif dump, setup the new directory server and try an import.
You will encounter any missing stuff by trial and error.
check the log files and see how you go :).
On Mon, Mar 17,
I encountered a similar issue.
I got it when creating an index with the vlvindex command, which was
apparently not correct.
The index creation failed with a segfault and after that I could not
start the server anymore.
I was also unable to do deletion of the index, since ldap was not up.
The error
I verified this behaviour is still present in Fedora 389 Directory Server 1.2.6.
On Fri, May 24, 2013 at 3:21 PM, Vincent Gerris vger...@gmail.com wrote:
Hi all,
I think I found it, it seems a bug to me.
With audit logging enabled, I noticed a difference in output in the
output log when
Hi Thierry,
Agreed that it might be handy, but we have no password policy enabled.
Thus, these actions should not be enabled imho.
Any way to disable it? Thanks,
Kind regards,
Vincent
On 24 May 2013 19:04, thierry bordaz tbor...@redhat.com wrote:
On 05/24/2013 04:16 PM, Vincent Gerris wrote
password policy.
Googling did not help either.
Any help is greatly appreciated!
On Fri, May 24, 2013 at 3:38 PM, Vincent Gerris vger...@gmail.com wrote:
I verified this behaviour is still present in Fedora 389 Directory Server
1.2.6.
On Fri, May 24, 2013 at 3:21 PM, Vincent Gerris vger
hi,
I noticed this entry when trying to use the db2bak.pl script.
I found out that the -a option only works when for example
the /var/lib/dirsrv/slapd-server/bak or a subdir is used (effectively)
the same dir as without the -a option.
I was using a root dir, which I also modded with nobody:nobody
it helps others too :).
Greetings Vincent
On Mon, May 13, 2013 at 5:48 PM, Rich Megginson rmegg...@redhat.com wrote:
On 05/13/2013 09:09 AM, Vincent Gerris wrote:
hi,
I noticed this entry when trying to use the db2bak.pl script.
I found out that the -a option only works when for example
19 matches
Mail list logo