I would like to be able to Azure AD join machines.
My environment is Federated with SAML2 identity provider Internet2 Shibboleth (that does not implement WS-Fed or WS-Trust).
Is it doable to deploy a Pass-through Authentication througth Azure Authentication Agents to allow Azure AD join and Windows logon from joined devices while at the same time doing web authentication (like on https://www.office.com for example) with Internet2 Shibboleth as we are doing now?
Ansible, when driven by a user with MFA, needs to give the verification code asked by sshd from the target host. I can type it in, but when a playbooks runs for many hosts, I would need to type as many times as my hosts.
I am looking for something like:
yes 101010 | ansible-playbooks playbook.yaml
where 101010 is the verification code (which is the same for all the hosts).
After converting from freeradius2 to freeradius3 found out rlm_ldap is really chatty:
Fri Feb 2 08:02:51 2018 : Info: rlm_ldap (ldap): Closing connection (79): Hit idle_timeout, was idle for 202 seconds
Fri Feb 2 08:02:51 2018 : Info: rlm_ldap (ldap): Closing connection (80): Hit idle_timeout, was idle for 202 seconds
Fri Feb 2 08:02:51 2018 : Info: rlm_ldap (ldap): Opening additional connection (81), 1 of 32 pending slots used
Fri Feb 2 08:02:51 2018 : Info: Need 2 more connections to reach min connections (3)
I would like radius.log to only have auth msg lines:
Fri Feb 2 08:02:51 2018 : Auth: (3951) Login OK: [user] (from client aphub port 1 cli FA-KE-MA-CA-DD-RE)
But I can't find how to disable logging selectively on a single module.
Follows one hour log from rlm_ldap:
Fri Feb 9 10:06:02 2018 : Info: rlm_ldap (ldap2): Closing connection (1320): Hit idle_timeout, was idle for 430 seconds Fri Feb 9 10:06:02 2018 : Info: rlm_ldap (ldap2): Closing connection (1319): Hit idle_timeout, was idle for 430 seconds Fri Feb 9 10:06:02 2018 : Info: rlm_ldap (ldap2): Opening additional connection (1321), 1 of 32 pending slots used Fri Feb 9 10:06:03 2018 : Info: Need 2 more connections to reach min connections (3) Fri Feb 9 10:06:03 2018 : Info: rlm_ldap (ldap2): Opening additional connection (1322), 1 of 31 pending slots used Fri Feb 9 10:06:03 2018 : Info: rlm_ldap (ldap2-secondary): Closing connection (1227): Hit idle_timeout, was idle for 431 seconds Fri Feb 9 10:06:03 2018 : Info: rlm_ldap (ldap2-secondary): Closing connection (1228): Hit idle_timeout, was idle for 431 seconds Fri Feb 9 10:06:03 2018 : Info: rlm_ldap (ldap2-secondary): Opening additional connection (1229), 1 of 32 pending slots used Fri Feb 9 10:06:03 2018 : Info: Need 2 more connections to reach min connections (3) Fri Feb 9 10:06:03 2018 : Info: rlm_ldap (ldap2-secondary): Opening additional connection (1230), 1 of 31 pending slots used Fri Feb 9 10:11:20 2018 : Info: rlm_ldap (ldap2): Closing connection (1322): Hit idle_timeout, was idle for 317 seconds Fri Feb 9 10:11:20 2018 : Info: rlm_ldap (ldap2): Closing connection (1321): Hit idle_timeout, was idle for 317 seconds Fri Feb 9 10:11:20 2018 : Info: rlm_ldap (ldap2): Opening additional connection (1323), 1 of 32 pending slots used Fri Feb 9 10:11:20 2018 : Info: Need 2 more connections to reach min connections (3) Fri Feb 9 10:11:20 2018 : Info: rlm_ldap (ldap2): Opening additional connection (1324), 1 of 31 pending slots used Fri Feb 9 10:11:20 2018 : Info: rlm_ldap (ldap2-secondary): Closing connection (1229): Hit idle_timeout, was idle for 317 seconds Fri Feb 9 10:11:20 2018 : Info: rlm_ldap (ldap2-secondary): Closing connection (1230): Hit idle_timeout, was idle for 317 seconds Fri Feb 9 10:11:20 2018 : Info: rlm_ldap (ldap2-secondary): Opening additional connection (1231), 1 of 32 pending slots used Fri Feb 9 10:11:20 2018 : Info: Need 2 more connections to reach min connections (3) Fri Feb 9 10:11:20 2018 : Info: rlm_ldap (ldap2-secondary): Opening additional connection (1232), 1 of 31 pending slots used Fri Feb 9 10:18:22 2018 : Info: rlm_ldap (ldap2): Closing connection (1324): Hit idle_timeout, was idle for 422 seconds Fri Feb 9 10:18:22 2018 : Info: rlm_ldap (ldap2): Closing connection (1323): Hit idle_timeout, was idle for 422 seconds Fri Feb 9 10:18:22 2018 : Info: rlm_ldap (ldap2): Opening additional connection (1325), 1 of 32 pending slots used Fri Feb 9 10:18:23 2018 : Info: Need 2 more connections to reach min connections (3) Fri Feb 9 10:18:23 2018 : Info: rlm_ldap (ldap2): Opening additional connection (1326), 1 of 31 pending slots used Fri Feb 9 10:18:23 2018 : Info: rlm_ldap (ldap2-secondary): Closing connection (1231): Hit idle_timeout, was idle for 423 seconds Fri Feb 9 10:18:23 2018 : Info: rlm_ldap (ldap2-secondary): Closing connection (1232): Hit idle_timeout, was idle for 423 seconds Fri Feb 9 10:18:23 2018 : Info: rlm_ldap (ldap2-secondary): Opening additional connection (1233), 1 of 32 pending slots used Fri Feb 9 10:18:23 2018 : Info: Need 2 more connections to reach min connections (3) Fri Feb 9 10:18:23 2018 : Info: rlm_ldap (ldap2-secondary): Opening additional connection (1234), 1 of 31 pending slots used Fri Feb 9 10:22:24 2018 : Info: rlm_ldap (ldap2): Closing connection (1326): Hit idle_timeout, was idle for 241 seconds Fri Feb 9 10:22:24 2018 : Info: rlm_ldap (ldap2): Closing connection (1325): Hit idle_timeout, was idle for 241 seconds Fri Feb 9 10:22:24 2018 : Info: rlm_ldap (ldap2): Opening additional connection (1327), 1 of 32 pending slots used Fri Feb 9 10:22:24 2018 : Info: Need 2 more connections to reach min connections (3) Fri Feb 9 10:22:24 2018 : Info: rlm_ldap (ldap2): Opening additional connection (1328), 1 of 31 pending slots used Fri Feb 9 10:22:24 2018 : Info: rlm_ldap (ldap2-secondary): Closing connection (1233): Hit idle_timeout, was idle for 241 seconds Fri Feb 9 10:22:24 2018 : Info: rlm_ldap (ldap2-secondary): Closing connection (1234): Hit idle_timeout, was idle for 241 seconds Fri Feb 9 10:22:24 2018 : Info: rlm_ldap (ldap2-secondary): Opening additional connection (1235), 1 of 32 pending slots used Fri Feb 9 10:22:24 2018 : Info: Need 2 more connections to reach min connections (3) Fri Feb 9 10:22:24 2018 : Info: rlm_ldap (ldap2-secondary): Opening additional connection (1236), 1 of 31 pending slots used Fri Feb 9 10:51:55 2018 : Info: rlm_ldap (ldap2): Closing connection (1328): Hit idle_timeout, was idle for 1771 seconds Fri Feb 9 10:51:55 2018 : Info: rlm_ldap (ldap2): Closing connection (1327): Hit idle_timeout, was idle for 1771 seconds Fri Feb 9 10:51:55 2018 : Info: rlm_ldap (ldap2): Opening additional connection (1329), 1 of 32 pending slots used Fri Feb 9 10:51:55 2018 : Info: Need 2 more connections to reach min connections (3) Fri Feb 9 10:51:55 2018 : Info: rlm_ldap (ldap2): Opening additional connection (1330), 1 of 31 pending slots used Fri Feb 9 10:51:55 2018 : Info: rlm_ldap (ldap2-secondary): Closing connection (1235): Hit idle_timeout, was idle for 1771 seconds Fri Feb 9 10:51:55 2018 : Info: rlm_ldap (ldap2-secondary): Closing connection (1236): Hit idle_timeout, was idle for 1771 seconds Fri Feb 9 10:51:55 2018 : Info: rlm_ldap (ldap2-secondary): Opening additional connection (1237), 1 of 32 pending slots used Fri Feb 9 10:51:55 2018 : Info: Need 2 more connections to reach min connections (3) Fri Feb 9 10:51:55 2018 : Info: rlm_ldap (ldap2-secondary): Opening additional connection (1238), 1 of 31 pending slots used Fri Feb 9 10:55:54 2018 : Info: rlm_ldap (ldap2): Closing connection (1330): Hit idle_timeout, was idle for 239 seconds Fri Feb 9 10:55:54 2018 : Info: rlm_ldap (ldap2): Closing connection (1329): Hit idle_timeout, was idle for 239 seconds Fri Feb 9 10:55:54 2018 : Info: rlm_ldap (ldap2): Opening additional connection (1331), 1 of 32 pending slots used Fri Feb 9 10:55:54 2018 : Info: Need 2 more connections to reach min connections (3) Fri Feb 9 10:55:54 2018 : Info: rlm_ldap (ldap2): Opening additional connection (1332), 1 of 31 pending slots used Fri Feb 9 10:55:54 2018 : Info: rlm_ldap (ldap2-secondary): Closing connection (1237): Hit idle_timeout, was idle for 239 seconds Fri Feb 9 10:55:54 2018 : Info: rlm_ldap (ldap2-secondary): Closing connection (1238): Hit idle_timeout, was idle for 239 seconds Fri Feb 9 10:55:54 2018 : Info: rlm_ldap (ldap2-secondary): Opening additional connection (1239), 1 of 32 pending slots used Fri Feb 9 10:55:54 2018 : Info: Need 2 more connections to reach min connections (3) Fri Feb 9 10:55:54 2018 : Info: rlm_ldap (ldap2-secondary): Opening additional connection (1240), 1 of 31 pending slots used Fri Feb 9 10:56:14 2018 : Info: Need 1 more connections to reach min connections (3) Fri Feb 9 10:56:14 2018 : Info: rlm_ldap (ldap2): Opening additional connection (1333), 1 of 30 pending slots used Fri Feb 9 10:56:14 2018 : Info: Need 1 more connections to reach min connections (3) Fri Feb 9 10:56:14 2018 : Info: rlm_ldap (ldap2-secondary): Opening additional connection (1241), 1 of 30 pending slots used Fri Feb 9 10:56:15 2018 : Info: Need 7 more connections to reach 10 spares Fri Feb 9 10:56:15 2018 : Info: rlm_ldap (ldap2): Opening additional connection (1334), 1 of 29 pending slots used
In the same time slice 19 Auth happened.
On Debian, the exim4 key file is supposed to be /etc/exim4/exim.key with permissions:
chmod 640 exim.key
chown root:Debian-exim exim.key
If I have already a key file in /etc/ssl/private, owned by group ssl-cert, how can I recycle it for exim?
If I change the group of /etc/ssl/private dir to Debian-exim it works, but then for instance I would need to add openldap to the Debian-exim group, in order to use the key for slapd. Pretty unobvious, isn't it?
Adding Debian-exim to the ssl-cert group doesn't work: it is the exim software itself to blame the configuration as unsafe.
Which is the best-practice solution?
I would need to set a trust relation between a NT4 samba domain and another samba domain but AD.
The trust does not need to be bi-directional and either way is fine.
Which way does it work given both samba versions are 4.7.3?
Where can I find documentation on this issue?
The nmbd logs of a linux samba4 domain member server are filled with lines like:
query_name_response: Multiple (2) responses received for a query on subnet 192.168.1.54 for name ADOMAIN<1d>.
This response was from IP 192.168.1.19, reporting an IP address of 192.168.1.19.
where:
ADOMAIN is a SAMBA NT-style domainThose lines appears every 5 minutes.
What is going on?
Random steps taken:
rm /var/cache/samba/browse.dat;interfaces broadcast configuration (it is correct);systemctl restart nmbd (a evergreen classic).
I am not able to receive on jetty-9.3.14 the X509 client cert data which are submitted to apache2 and forwarded via ProxyPass directive.
<Location /X509>
SSLVerifyClient require
SSLVerifyDepth 5
SSLOptions -StdEnvVars +ExportCertData
# most of the followings are useless
RequestHeader set SSL_CLIENT_S_DN "%{SSL_CLIENT_S_DN}s"
RequestHeader set SSL_CLIENT_I_DN "%{SSL_CLIENT_I_DN}s"
RequestHeader set SSL_SERVER_S_DN_OU "%{SSL_SERVER_S_DN_OU}s"
RequestHeader set SSL_CLIENT_VERIFY "%{SSL_CLIENT_VERIFY}s"
RequestHeader set SSL_CLIENT_V_START "%{SSL_CLIENT_V_START}s"
RequestHeader set SSL_CLIENT_V_END "%{SSL_CLIENT_V_END}s"
RequestHeader set SSL_CLIENT_M_VERSION "%{SSL_CLIENT_M_VERSION}s"
RequestHeader set SSL_CLIENT_M_SERIAL "%{SSL_CLIENT_M_SERIAL}s"
RequestHeader set SSL_CLIENT_CERT "%{SSL_CLIENT_CERT}s"
RequestHeader set SSL_CLIENT_VERIFY "%{SSL_CLIENT_VERIFY}s"
RequestHeader set SSL_SERVER_M_VERSION "%{SSL_SERVER_M_VERSION}s"
RequestHeader set SSL_SERVER_I_DN "%{SSL_SERVER_I_DN}s"
RequestHeader set SSL_SERVER_CERT "%{SSL_SERVER_CERT}s"
</Location>
The above location on apache2 is effective in requiring X509 client cert to user, but these information are not forwarded to jetty.
My kerberos domain in MYEXAMPLE.ORG, but servers are located in the dmz-int.example.org dns zone.
LDAP server is b1.dmz-int.example.org; its keytab include:
udo ktutil -k /etc/krb5.keytab list /etc/krb5.keytab: Vno Type Principal Aliases 7 arcfour-hmac-md5 [email protected] 7 aes128-cts-hmac-sha1-96 [email protected] 7 aes256-cts-hmac-sha1-96 [email protected] 7 arcfour-hmac-md5 host/[email protected] 7 aes128-cts-hmac-sha1-96 host/[email protected] 7 aes256-cts-hmac-sha1-96 host/[email protected] 7 arcfour-hmac-md5 ldap/[email protected] 7 aes128-cts-hmac-sha1-96 ldap/[email protected] 7 aes256-cts-hmac-sha1-96 ldap/[email protected] 7 arcfour-hmac-md5 ldap/[email protected] 7 aes128-cts-hmac-sha1-96 ldap/[email protected] 7 aes256-cts-hmac-sha1-96 ldap/[email protected] 7 arcfour-hmac-md5 ldap/[email protected] 7 aes128-cts-hmac-sha1-96 ldap/[email protected] 7 aes256-cts-hmac-sha1-96 ldap/[email protected]
ldap2.myexample.org is a CNAME of b1.dmz-int.example.org
Now I can connect with GSSAPI to LDAP server:
$ kinit
$ ldapsearch -ZZ -h b1.dmz-int.example.org 'uid=test'
SASL/GSSAPI authentication started
SASL username: [email protected]
SASL SSF: 56
SASL data security layer installed.
[...]
$ ldapsearch -ZZ -h ldap2.myexample.org 'uid=test'
SASL/GSSAPI authentication started
SASL username: [email protected]
SASL SSF: 56
SASL data security layer installed.
[...]
$ klist
Credentials cache: FILE:/tmp/krb5cc_1000
Principal: [email protected]
Issued Expires Principal
Sep 6 09:03:35 2016 Sep 6 19:03:32 2016 krbtgt/[email protected]
Sep 6 09:03:39 2016 Sep 6 19:03:32 2016 ldap/[email protected]
Looks fine.
Now comes the proxy.
Proxy A record is ldap.dmz-int.example.org and it has a CNAME as ldap.myexample.org.
Proxy is a HAPROXY layer 4 for ports 389 and 636. Without SASL it works fine.
$ ldapsearch -ZZ -h ldap.myexample.org 'uid=test'
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure (see text) (Matching credential (ldap/[email protected]) not found)
$ ldapsearch -h ldap.dmz-int.example.org 'uid=test'
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure (see text) (Matching credential (ldap/[email protected]) not found)
And now SASL doesn't work. Do I need an extra SPN in the server keytab? Do I need some dns fixes? Why the proxy query looks for the: ldap/[email protected] principal and not ldap/[email protected]?
As a reference, follows the haproxy conf file:
$ cat /etc/haproxy/haproxy.cfg
global
log /dev/log local0
# log /dev/log local1 notice
chroot /var/lib/haproxy
stats socket /run/haproxy/admin.sock mode 660 level admin
stats timeout 30s
user haproxy
group haproxy
daemon
# Default SSL material locations
ca-base /etc/ssl/certs
crt-base /etc/ssl/private
# Default ciphers to use on SSL-enabled listening sockets.
# For more information, see ciphers(1SSL). This list is from:
# https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/
ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS
ssl-default-bind-options no-sslv3
# LDAP and LDAP/STARTTLS
frontend ldap_service_front
log global
mode tcp
bind *:389
description LDAP Service
option socket-stats
option tcpka
option tcplog
timeout client 10s
default_backend ldap_service_back
backend ldap_service_back
log global
server ldap-1 b1.myexample.org:389 check fall 1 rise 1 inter 2s
server ldap-2 b2.myexample.org:389 check fall 1 rise 1 inter 2s
mode tcp
balance leastconn
option tcpka
option ldap-check
timeout server 10s
timeout connect 1s
In a Debian GNU/Linux environment, I am not able to have SASL work with kerberos:
sudo /usr/sbin/sasl-sample-server -m GSSAPI -s ldap Forcing use of mechanism GSSAPI Sending list of 1 mechanism(s) S: R1NTQVBJ Waiting for client mechanism... C: [...a lot of lines trimmed...] got 'GSSAPI' sasl-sample-server: SASL Other: GSSAPI Error: No credentials were supplied, or the credentials were unavailable or inaccessible. (unknown mech-code 0 for mech unknown) sasl-sample-server: Starting SASL negotiation: generic failure (generic failure)
Documentation says it's the service that can't access keytab.
But:
strace I can confirm the file /etc/krb5.keytab is accessed.I am running out of ideas: what should I check now?
The message error is two-folded: I checked mainly the or the credentials were unavailable or inaccessible part; what does the No credentials were supplied part mean?
Starting from the following example (citated on samba wiki):
$host -t SRV _ldap._tcp.samdom.example.com.
_ldap._tcp.samdom.example.com has SRV record 0 100 389 dc1.samdom.example.com.
What do the integers in the response mean?
389 is likely the TCP port involved, but 0? and 100?
I would like to upgrade the Debian stock kernel to a compiled kernel packed as a .deb package.
Running the:
dpkg -i linux-image-x.x.Custom_amd64.deb
triggers the grub-update and, as I see from filesystem, the creation of the initrd file.
But now, how I tell EXTLINUX to boot from the new kernel?
Context: I am working with a Samba PDC (not AD mode) which emulate a MS NT Server 3.5.
My problem is with the following line on smb.conf:
logon home = \\%L\%U
This line makes users mount a home share named after their username called with the alphabeth letter specified in the user's LDAP entry:
sambaHomeDrive: Y:
My question is: may I change logon home to
logon home = \\my_store_server\%U
Or I am forced to have homes on PDC?
The following startup script for systemd (Debian GNU/Linux Jessie)
[Unit]
Description=Apache httpd web server
After=network.target
[Service]
PIDFile=/var/run/apache2/apache2.pid
EnvironmentFile=/etc/default/apache2
EnvironmentFile=/etc/apache2/envvars
ExecStart=/usr/sbin/apache2 -d /etc/apache2 -k start
[Install]
WantedBy=multi-user.target
does not work because the executable doesn't pick up the env variables in the EnvironmentFile.
This is what I read in /var/log/daemon.log on service start:
Nov 23 10:05:30 kdc apache2[3111]: AH00526: Syntax error on line 74 of /etc/apache2/apache2.conf:
Nov 23 10:05:30 kdc apache2[3111]: Invalid Mutex directory in argument file:${APACHE_LOCK_DIR}
APACHE_LOCK_DIR is defined in /etc/apache2/envvars which is stock debian stuff:
# envvars - default environment variables for apache2ctl
# this won't be correct after changing uid
unset HOME
# for supporting multiple apache2 instances
if [ "${APACHE_CONFDIR##/etc/apache2-}" != "${APACHE_CONFDIR}" ] ; then
SUFFIX="-${APACHE_CONFDIR##/etc/apache2-}"
else
SUFFIX=
fi
# Since there is no sane way to get the parsed apache2 config in scripts, some
# settings are defined via environment variables and then used in apache2ctl,
# /etc/init.d/apache2, /etc/logrotate.d/apache2, etc.
export APACHE_RUN_USER=www-data
export APACHE_RUN_GROUP=www-data
# temporary state file location. This might be changed to /run in Wheezy+1
export APACHE_PID_FILE=/var/run/apache2/apache2$SUFFIX.pid
export APACHE_RUN_DIR=/var/run/apache2$SUFFIX
export APACHE_LOCK_DIR=/var/lock/apache2$SUFFIX
# Only /var/log/apache2 is handled by /etc/logrotate.d/apache2.
export APACHE_LOG_DIR=/var/log/apache2$SUFFIX
## The locale used by some modules like mod_dav
export LANG=C
## Uncomment the following line to use the system default locale instead:
#. /etc/default/locale
export LANG
## The command to get the status for 'apache2ctl status'.
## Some packages providing 'www-browser' need '--dump' instead of '-dump'.
#export APACHE_LYNX='www-browser -dump'
## If you need a higher file descriptor limit, uncomment and adjust the
## following line (default is 8192):
#APACHE_ULIMIT_MAX_FILES='ulimit -n 65536'
## If you would like to pass arguments to the web server, add them below
## to the APACHE_ARGUMENTS environment.
#export APACHE_ARGUMENTS=''
## Enable the debug mode for maintainer scripts.
## This will produce a verbose output on package installations of web server modules and web application
## installations which interact with Apache
#export APACHE2_MAINTSCRIPT_DEBUG=1
I have some more warnings about other environment variables, so I need systemd to read the env files. Really.
I would like to add via puppet a system user to Debian boxes.
The user is:
user { 'puppet':
ensure => 'present',
comment => 'puppetserver daemon',
gid => '109',
groups => ['www-data'],
home => '/opt/puppetlabs/server/data/puppetserver',
shell => '/bin/false',
uid => '107',
}
(uid and gid taken from user created by the package puppetserver).
Can I be confident uid 107 is not already taken on some boxes by other services? Are there safe uids on Debian? How does it work the system users' uid allocation in Debian?
I would like to be able to syncrepl only a subtree of cn=config, namely cn=schema,cn=config:
# {0}config, config
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external
,cn=auth manage by * break
olcAccess: {1}to * by * none
olcRootDN: cn=admin,cn=config
olcRootPW: {SSHA}just_another_secret
olcSyncUseSubentry: FALSE
olcSyncrepl: {0}rid=001 provider=ldap://provider.example.org binddn="cn=consumer
,dc=example,dc=org" bindmethod=simple credentials="secret" searchbase="cn=sch
ema,cn=config" type=refreshOnly filter="(!(cn=*core))" interval=00:00:30:00
retry="5 5 30 +" timeout=1 scope=sub schemachecking=on starttls=yes
But, if I define cn=config as a shadow tree (even for a subtree, see searchbase) I am not longer allowed to modify it.
My error is:
modifying entry "cn=config"
ldap_modify: Server is unwilling to perform (53)
additional info: shadow context; no update referral
even if I try to modify the attribute 'olcLogLevel', located in cn=config which is up-level respect the syncrepl-icated cn=schema,cn=config.
Which is the correct way to syncrepl just a subtree of cn=config?
I am missing a bit of feedback from systemd commands. After issuing a
systemctl restart my_service
there is no output and to receive confirmation if my_service is started, I need type
systemctl status my_service
Is there a way to have at least a line explaing what systemd did, and maybe also if service failed to start or was successful?
While doing apt-get dist-upgrade on a Debian GNU/Linux Jessie EXTLINUX warned me that now was mandatory to install grub.
The system was installed after an image not done by me: is it safe to ignore the warning? Have I to install grub also if now it's not installed and everything works (until I reboot, maybe)?
Can you please give me pointers?