On 12/12/19 11:58 AM, Alberto Viana wrote:
Hi Guys,
Already found the problem with the regular user (it was a misconfiguration).
Thanks!!!
Great!
Alberto Viana
On Thu, Dec 12, 2019 at 1:49 PM Alberto Viana <albertocrj@gmail.com mailto:albertocrj@gmail.com> wrote:
Mark, Thanks, that was de trick, but it only works with root, if i try a user in the wheel/sudo group, shows me that message: ~# id myuser uid=1002(myuser) gid=1002(myuser) groups=1002(myuser),10(wheel) Does not suppose to work? Thanks. On Thu, Dec 12, 2019 at 1:43 PM Mark Reynolds <mreynolds@redhat.com <mailto:mreynolds@redhat.com>> wrote: On 12/12/19 11:34 AM, Alberto Viana wrote:
Viktor, Sorry, forgot to mention that. It was created using dscreate with a template file: dscreate from-file rnp-template and the log shows me that LDAPI is enabled: [12/Dec/2019:15:39:31.407250429 +0000] - INFO - slapd_daemon - Listening on /var/run/slapd-RNP.socket for LDAPI requests
You must log into the cockpit as root, or an account with sudo privileges, otherwise it can't read /etc/dirsrv There could also be more info in the browser's console log (press F12). HTH, Mark
Thanks, Alberto Viana On Thu, Dec 12, 2019 at 1:29 PM Viktor Ashirov <vashirov@redhat.com <mailto:vashirov@redhat.com>> wrote: Hi, On Thu, Dec 12, 2019 at 5:18 PM Alberto Viana <albertocrj@gmail.com <mailto:albertocrj@gmail.com>> wrote: Hi Guys, I have installed 389 from source (389-Directory/1.4.2.4 <http://1.4.2.4> B2019.344.19) Installed 389-ds cockpit plugin via npm e copy to /usr/share/cockpit/389-console/ cockpit-195.1-1.el7.centos.0.1.x86_64 When I login into cockpit, it says there's no instance: How did you create your instance? Using dscreate or setup-ds.pl <http://setup-ds.pl>? setup-ds.pl <http://setup-ds.pl> is deprecated and not supported with the new web UI, it doesn't configure LDAPI socket needed for communication between the server and cockpit. dscreate does create it by default. Screen Shot 2019-12-12 at 12.55.33.png but I created one manually: ~# dsctl -l slapd-RNP ~# systemctl status dirsrv@RNP.service <mailto:dirsrv@RNP.service> ● dirsrv@RNP.service <mailto:dirsrv@RNP.service> - 389 Directory Server with ASAN RNP. Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled; vendor preset: disabled) Drop-In: /usr/lib/systemd/system/dirsrv@.service.d └─xsan.conf Active: active (running) since Thu 2019-12-12 15:39:31 UTC; 34min ago Process: 1932 ExecStartPre=/usr/libexec/ds_systemd_ask_password_acl /etc/dirsrv/slapd-%i/dse.ldif (code=exited, status=0/SUCCESS) Main PID: 1956 (ns-slapd) Status: "slapd started: Ready to process requests" CGroup: /system.slice/system-dirsrv.slice/dirsrv@RNP.service └─1956 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-RNP -i /run/dirsrv/slapd-RNP.pid ~# netstat -natp tcp6 0 0 :::636 :::* LISTEN 1956/ns-slapd tcp6 0 0 :::389 :::* LISTEN 1956/ns-slapd /usr/share/cockpit/389-console/ds.js: var DS_HOME = "/etc/dirsrv/"; var server_id = "None"; var server_inst = ""; var dn_regex = new RegExp( "^([A-Za-z]+=.*)" ); ls -lha /etc/dirsrv/ total 16K drwxr-xr-x. 6 dirsrv dirsrv 63 Dec 9 17:25 . drwxr-xr-x. 83 root root 8.0K Dec 12 15:39 .. drwxr-xr-x. 2 dirsrv dirsrv 78 Dec 10 01:10 config drwxr-xr-x. 2 dirsrv dirsrv 25 Dec 10 01:10 schema drwxrwx---. 3 dirsrv dirsrv 4.0K Dec 12 15:39 slapd-RNP drwxrwx---. 2 dirsrv dirsrv 155 Dec 9 17:25 ssca Also tried to disable selinux, but the behavior is the same. What am I missing? How can I debug it? Thanks Alberto Viana _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org -- Viktor _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org _______________________________________________ 389-users mailing list --389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> To unsubscribe send an email to389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
-- 389 Directory Server Development Team
On 13 Dec 2019, at 02:59, Mark Reynolds mreynolds@redhat.com wrote:
On 12/12/19 11:58 AM, Alberto Viana wrote:
Hi Guys,
Already found the problem with the regular user (it was a misconfiguration).
Thanks!!!
Great!
Alberto Viana
On Thu, Dec 12, 2019 at 1:49 PM Alberto Viana albertocrj@gmail.com wrote: Mark,
Thanks, that was de trick, but it only works with root, if i try a user in the wheel/sudo group, shows me that message:
~# id myuser uid=1002(myuser) gid=1002(myuser) groups=1002(myuser),10(wheel)
I wonder if adding the user do group "dirsrv" would also work? (Not actual advice, please don't try in production, this is more for Mreynolds to think about :) )
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs
389-users@lists.fedoraproject.org