cockpit handlebars warning (npm)
by Alberto Viana
Hi,
During my tests and install of 389-ds cockpit plugin via npm I got this
warning:
"overview": "Versions of `handlebars` prior to 4.5.3 are vulnerable to
prototype pollution. It is possible to add or modify properties to the
Object prototype through a malicious template. This may allow attackers to
crash the application or execute Arbitrary Code in specific conditions.",
"recommendation": "Upgrade to version 4.5.3 or later.",
I had to update package-lock.json pointing to the latest version
of handlebars(4.5.3) in order to install it.
Just to let you guys know.
Cheers,
Alberto Viana
4 years, 3 months
Re: cockpit problems
by Mark Reynolds
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(a)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(a)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(a)redhat.com <mailto:vashirov@redhat.com>> wrote:
>>
>> Hi,
>>
>>
>> On Thu, Dec 12, 2019 at 5:18 PM Alberto Viana
>> <albertocrj(a)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(a)RNP.service
>> <mailto:dirsrv@RNP.service>
>> ● dirsrv(a)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(a)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(a)lists.fedoraproject.org
>> <mailto:389-users@lists.fedoraproject.org>
>> To unsubscribe send an email to
>> 389-users-leave(a)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.fedoraproje...
>>
>>
>>
>> --
>> Viktor
>> _______________________________________________
>> 389-users mailing list --
>> 389-users(a)lists.fedoraproject.org
>> <mailto:389-users@lists.fedoraproject.org>
>> To unsubscribe send an email to
>> 389-users-leave(a)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.fedoraproje...
>>
>>
>> _______________________________________________
>> 389-users mailing list --389-users(a)lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>
>> To unsubscribe send an email to389-users-leave(a)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.fe...
>
> --
>
> 389 Directory Server Development Team
>
--
389 Directory Server Development Team
4 years, 3 months
Re: cockpit problems
by Mark Reynolds
On 12/12/19 11:49 AM, Alberto Viana 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?
It "should" as we call the cockpit API using the use superuser option:
var cmd = ["/bin/sh", "-c", "/usr/bin/ls -d " + DS_HOME + "slapd-*"];
cockpit.spawn(cmd, { superuser: true }).done(function(data) {
Did you check the box in the cockpit login page that says: Reuse my
password for privileged tasks ?
>
> Thanks.
>
>
>
> On Thu, Dec 12, 2019 at 1:43 PM Mark Reynolds <mreynolds(a)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(a)redhat.com <mailto:vashirov@redhat.com>> wrote:
>>
>> Hi,
>>
>>
>> On Thu, Dec 12, 2019 at 5:18 PM Alberto Viana
>> <albertocrj(a)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(a)RNP.service
>> <mailto:dirsrv@RNP.service>
>> ● dirsrv(a)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(a)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(a)lists.fedoraproject.org
>> <mailto:389-users@lists.fedoraproject.org>
>> To unsubscribe send an email to
>> 389-users-leave(a)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.fedoraproje...
>>
>>
>>
>> --
>> Viktor
>> _______________________________________________
>> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
>> <mailto:389-users@lists.fedoraproject.org>
>> To unsubscribe send an email to
>> 389-users-leave(a)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.fedoraproje...
>>
>>
>> _______________________________________________
>> 389-users mailing list --389-users(a)lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>
>> To unsubscribe send an email to389-users-leave(a)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.fe...
>
> --
>
> 389 Directory Server Development Team
>
--
389 Directory Server Development Team
4 years, 3 months
cockpit problems
by Alberto Viana
Hi Guys,
I have installed 389 from source (389-Directory/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:
[image: Screen Shot 2019-12-12 at 12.55.33.png]
but I created one manually:
~# dsctl -l
slapd-RNP
~# systemctl status dirsrv(a)RNP.service
● dirsrv(a)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(a)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
4 years, 3 months
Re: replication during indexing
by Mark Reynolds
On 12/9/19 4:13 PM, Crocker, Deborah wrote:
> I have a couple of consumers where I need to index a new attribute. Should I stop replication to them while this is taking place? Note that the index attribute will not be something that is replicated during this time.
Running an indexing task does not break replication. It will
potentially impact database performance during the indexing, but nothing
should break...
Mark
> TIA
>
> Deborah Crocker, PhD
> Systems Engineer III
> Office of Information Technology
> The University of Alabama
> Box 870346
> Tuscaloosa, AL 36587
> Office 205-348-3758 | Fax 205-348-9393
> deborah.crocker(a)ua.edu
>
>
>
> _______________________________________________
> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave(a)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.fedoraproje...
--
389 Directory Server Development Team
4 years, 3 months
userPassword changed to PBKDF2_SHA256 after bind
by Francesc Guasch
Hello.
After upgrade to 389 release 1.4 I experienced an odd behaviour.
If I add a new user, then I bind with that user. The userPassword
attribute gets changed to {PBKDF2_SHA256}.
These are the steps I follow to reproduce it:
1- add a new entry with MD5 password, it is like this: {MD5}N7...
2- connect to LDAP and bind with the user just created
3- connect with admin and retrieve the password, it is {PBKDF2_SHA256}
I may have been doing something wrong but my code worked on previous
releases of 389-ds.
I extracted code from my project to build a full test on it. I uploaded
it to gist:
https://gist.github.com/frankiejol/9e099ba828c8cbdff361783c177643da
This is 1.4.1.6-4. So I have seen there is 1.4.2 release but
I haven't been able to build it. It gets stuck on make lib389
ModuleNotFoundError: No module named 'packaging'
make: *** [Makefile:14474: lib389] Error 1
Anyway, it looks like a bug or maybe a configuration issue ?
thank you for your time
4 years, 3 months
replication during indexing
by Crocker, Deborah
I have a couple of consumers where I need to index a new attribute. Should I stop replication to them while this is taking place? Note that the index attribute will not be something that is replicated during this time.
TIA
Deborah Crocker, PhD
Systems Engineer III
Office of Information Technology
The University of Alabama
Box 870346
Tuscaloosa, AL 36587
Office 205-348-3758 | Fax 205-348-9393
deborah.crocker(a)ua.edu
4 years, 3 months
Announcing 389 Directory Server 1.4.2.5
by Mark Reynolds
389 Directory Server 1.4.2.5
The 389 Directory Server team is proud to announce 389-ds-base version
1.4.2.5
Fedora packages are available on Fedora 31 and rawhide.
https://koji.fedoraproject.org/koji/taskinfo?taskID=39454569
<https://koji.fedoraproject.org/koji/taskinfo?taskID=39454569> - Rawhide
https://koji.fedoraproject.org/koji/taskinfo?taskID=39454576
<https://koji.fedoraproject.org/koji/taskinfo?taskID=39454576> - Fedora 31
Bodhi
https://bodhi.fedoraproject.org/updates/FEDORA-2019-ad190c32de
<https://bodhi.fedoraproject.org/updates/FEDORA-2019-ad190c32de>
The new packages and versions are:
* 389-ds-base-1.4.2.5-2
Source tarballs are available for download at Download
389-ds-base Source
<https://releases.pagure.org/389-ds-base/389-ds-base-1.4.2.5.tar.bz2>
Highlights in 1.4.2.5
* Bug fixes
Installation and Upgrade
See Download <https://www.port389.org/docs/389ds/download.html> for
information about setting up your yum repositories.
To install the server use *dnf install 389-ds-base*
To install the Cockpit UI plugin use *dnf install cockpit-389-ds*
After rpm install completes, run *dscreate interactive*
For upgrades, simply install the package. There are no further
steps required.
There are no upgrade steps besides installing the new rpms
See Install_Guide
<https://www.port389.org/docs/389ds/howto/howto-install-389.html> for
more information about the initial installation and setup
See Source <https://www.port389.org/docs/389ds/development/source.html>
for information about source tarballs and SCM (git) access.
New UI Progress (Cockpit plugin)
The new UI is fully functional. There are still parts that need to be
converted to ReactJS, but every feature is available.
Configuration Tab
Functional
Written in ReactJS
Server Tab Yes No
Security Tab Yes Yes
Database Tab Yes Yes
Replication Tab Yes Yes
Schema Tab Yes No (coming soon)
Plugin Tab Yes Yes
Monitor Tab Yes Yes
Feedback
We are very interested in your feedback!
Please provide feedback and comments to the 389-users mailing list:
https://lists.fedoraproject.org/admin/lists/389-users.lists.fedoraproject...
If you find a bug, or would like to see a new feature, file it in our
Pagure project: https://pagure.io/389-ds-base
* Bump version to 1.4.2.5
* Issue 50747 - Port readnsstate to dsctl
* Issue 50758 - Enable CLI arg completion
* Issue 50753 - Dumping the changelog to a file doesn’t work
* Issue 50745 - ns-slapd hangs during CleanAllRUV tests
* Issue 50734 - lib389 creates non-SSCA cert DBs with misleading
README.txt
* Issue 48851 - investigate and port TET matching rules filter tests(cert)
* Issue 50443 - Create a module in lib389 to Convert a byte sequence
to a properly escaped for LDAP
* Issue 50664 - DS can fail to recover if an empty directory exists in db
* Issue 50736 - RetroCL trimming may crash at shutdown if trimming
configuration is invalid
* Issue 50741 - bdb_start - Detected Disorderly Shutdown last time
Directory Server was running
* Issue 50572 - After running cl-dump dbdir/cldb/*ldif.done are
not deleted
* Issue 50701 - Fix type in lint report
* Issue 50729 - add support for gssapi tests on suse
* Issue 50701 - Add additional healthchecks to dsconf
* Issue 50711 - ‘dsconf security’ lacks option for setting
nsTLSAllowClientRenegotiation attribute
* Issue 50439 - Update docker integration for Fedora
* Issue 48851 - Investigate and port TET matching rules filter
tests(last test cases for match)
* Issue 50499 - Fix npm audit issues
* Issue 50722 - Test IDs are not unique
* Issue 50712 - Version comparison doesn’t work correctly on git builds
* Issue 50499 - Fix npm audit issues
* Issue 50706 - Missing lib389 dependency - packaging
--
389 Directory Server Development Team
4 years, 3 months