Hi all,
Not really a bug report because I did not manage to figure out the cause.
However, after upgrading from FC31 to FC32 I could not login any more, due
to SELinux problems. Auto-relabeling did not work, nothing really...
... until I did dnf uninstall MonetDB-selinux.
I came to this point because trying to give systemd services the correct
labels with restorecon failed with an error referencing a monetdb specific
file.
I do not have the details unfortunately, but if you get problems, beware
that MonetDB SELinux package and systemd may interfere in some way beyond
my knowledge of these services.
Best regards,
Arjen
PS: Some output from logs:
sudo ausearch -c monetdb -m AVC,SELINUX_ERR
[..]
----
time->Sat May 2 20:57:01 2020
type=AVC msg=audit(1588445821.693:203): avc: denied { open } for
pid=1232 comm="monetdbd" path="/etc/resolv.conf" dev="dm-0" ino=3409775
scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:default_t:s0 tclass=file permissive=1
----
time->Sat May 2 21:12:56 2020
type=AVC msg=audit(1588446776.043:1194): avc: denied { execute } for
pid=2861 comm="(monetdbd)" name="monetdbd" dev="dm-0" ino=2147256
scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=1
trawcon="unconfined_u:object_r:monetdbd_exec_t:s0"
----
time->Sat May 2 21:12:56 2020
type=AVC msg=audit(1588446776.043:1195): avc: denied { execute_no_trans }
for pid=2861 comm="(monetdbd)" path="/usr/bin/monetdbd" dev="dm-0"
ino=2147256 scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=1
trawcon="unconfined_u:object_r:monetdbd_exec_t:s0"
----
time->Sat May 2 21:12:56 2020
type=AVC msg=audit(1588446776.044:1196): avc: denied { map } for
pid=2861 comm="monetdbd" path="/usr/bin/monetdbd" dev="dm-0" ino=2147256
scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=1
trawcon="unconfined_u:object_r:monetdbd_exec_t:s0"
----
time->Sat May 2 21:12:56 2020
type=AVC msg=audit(1588446776.714:1197): avc: denied { remove_name } for
pid=1232 comm="monetdbd" name="merovingian.pid" dev="tmpfs" ino=34369
scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=1
trawcon="system_u:object_r:monetdbd_var_run_t:s0"
----
time->Sat May 2 21:12:56 2020
type=AVC msg=audit(1588446776.714:1198): avc: denied { unlink } for
pid=1232 comm="monetdbd" name="merovingian.pid" dev="tmpfs" ino=34369
scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=1
----
time->Sat May 2 21:12:56 2020
type=AVC msg=audit(1588446776.714:1199): avc: denied { write } for
pid=1232 comm="monetdbd" name=".merovingian_lock" dev="dm-0" ino=5899443
scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=1
trawcon="system_u:object_r:monetdbd_lock_t:s0"
----
time->Sat May 2 21:13:15 2020
type=AVC msg=audit(1588446795.214:1209): avc: denied { read } for
pid=2925 comm="(monetdbd)" name="passwd" dev="dm-0" ino=524514
scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:var_t:s0
tclass=file permissive=1
----
time->Sat May 2 21:13:15 2020
type=AVC msg=audit(1588446795.214:1210): avc: denied { open } for
pid=2925 comm="(monetdbd)" path="/var/lib/sss/mc/passwd" dev="dm-0"
ino=524514 scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:var_t:s0 tclass=file permissive=1
----
time->Sat May 2 21:13:15 2020
type=AVC msg=audit(1588446795.214:1211): avc: denied { map } for
pid=2925 comm="(monetdbd)" path="/var/lib/sss/mc/passwd" dev="dm-0"
ino=524514 scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:var_t:s0 tclass=file permissive=1
----
time->Sat May 2 21:14:24 2020
type=AVC msg=audit(1588446864.487:1281): avc: denied { read } for
pid=3072 comm="(monetdbd)" name="passwd" dev="dm-0" ino=524514
scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:var_t:s0
tclass=file permissive=1
----
time->Sat May 2 21:14:24 2020
type=AVC msg=audit(1588446864.487:1282): avc: denied { open } for
pid=3072 comm="(monetdbd)" path="/var/lib/sss/mc/passwd" dev="dm-0"
ino=524514 scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:var_t:s0 tclass=file permissive=1
----
time->Sat May 2 21:14:24 2020
type=AVC msg=audit(1588446864.487:1283): avc: denied { map } for
pid=3072 comm="(monetdbd)" path="/var/lib/sss/mc/passwd" dev="dm-0"
ino=524514 scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:var_t:s0 tclass=file permissive=1
--
====================================================================
ICIS, office M1.00.05 Radboud University
Mercator 1 Faculty of Science
Toernooiveld 212 arjen(a)cs.ru.nl
NL-6525 EC Nijmegen, The Netherlands +31-(0)24-365 2354
===================== http://www.informagus.nl/ ====================
--
====================================================================
ICIS, office M1.00.05 Radboud University
Mercator 1 Faculty of Science
Toernooiveld 212 arjen(a)cs.ru.nl
NL-6525 EC Nijmegen, The Netherlands +31-(0)24-365 2354
===================== http://www.informagus.nl/ ====================
Hi there,
I looked around but couldn't find any recommendation about kernel vm
settings in Linux for MonetDB.
In particular:
- vm.overcommit_memory:
0 (default) : a heuristics decides whether overcommitting is allowed
1: no check, overcommit is always allowed
2: overcommitting is regulated by vm.overcommit_ratio (default = 50%)
Do I understand correctly that using vm.overcommit_memory=1 will only make
the OOM kill mserver5 when the total VM available is exhausted?
If that is true, should it be reasonably safe to use on a server that is
mainly intended for MonetDB, as long as sufficient disk space is available?
- vm.swappiness
Generic recommendations are usually 60 for a desktop and 30 for a server.
Oracle recommends 10.
Redis recommends 1.
Are there studies / recommendations for MonetDB?
Hi,
I work for Opentext corporation and one of my dev team is heavily using MonetDB and would like to explore if there's common interest on certain functionalities that we have developed. We would be interested to exchange information, solicit feedback and the possibility to contribute to the community.
Can someone please provide a few pointers as to how to proceed? Thanks in advance for your time and assistance.
Jamie
The MonetDB team at MonetDB BV is pleased to announce the
Oct2020-SP3 bugfix release of the MonetDB suite of programs.
More information about MonetDB can be found on our website at
<https://www.monetdb.org/>.
For details on this release, please see the release notes at
<https://www.monetdb.org/Downloads/ReleaseNotes>.
As usual, the download location is <https://www.monetdb.org/downloads/>.
Oct2020-SP3 Bugfix Release (11.39.13)
Bug Fixes
* 7049: Implement DISTINCT for GROUP_CONCAT
Hey,
MonetDB.Net is an entirely community driven project. Therefore, I cannot 100% guarantee it is production ready. I made some effort into testing it however, and it worked fine. If you encounter any problems, please feel free to post them here or on StackOverflow, or even to propose changes over on the GitHub repo.
Regards,
Mitchell.
Hi,
I am currently using Windows Monetdb ODBC driver to connect from .Net to a
running monetdb server.
Recently I found the github repo https://github.com/MonetDB/MonetDB-.Net
and do some initial testing and it's far better in error reporting and
support connection pooling.
How mature is this .Net connector and is it recommended for usage in
production environments and replace the ODBC driver? Is it the official
connector for .Net and backed by the Monetdb team?
Many thanks.
Hi,
After upgrading to the Oct 2020-SP2 (11.39.11) version the ODBC driver
started to throw the following exception:
ERROR [IM003] Specified driver could not be loaded due to system error
126: The specified module could not be found. (MonetDB ODBC Driver,
C:\Program Files\MonetDB\MonetDB ODBC Driver\lib\MonetODBC.dll)
Rolling back the driver to the version june 2020-SP1(11.37.11.01) the
driver is working fine.
Previously some driver releases missed the 2 libraries "libeay32.dll" and
"ssleay32.dll", and adding them to the ODBC driver installation folder
solved the problem, but not this time.
Is there any missing dlls in the installation or its a more complicated
issue.
Thanks. Regards