I'm currently working on a project where some install script of some other teams are creating a lot of files/scripts and others various stuff in a folder located in /. eg: /installfolder
Is that considered bad practice ? Wouldn't be better to store everything in /opt/lovelyfolder instead ?
We've recently upgraded from MySQL Percona 5.7 to 8 and we're in the phase of transitioning from mysql_native_password to caching_sha2_password.
As far as I understand, the only way to upgrade the Plugin is with the below query, and if no password is supplied, an empty one will.
mysql> ALTER USER 'user'@'host' IDENTIFIED WITH caching_sha2_password BY 'password';
The two questions I have are the following.
However prior any changes, is the debian-sys-maint still relevant in Stretch - MySQL 8 ? What would it imply to remove that account ? Considering that root has replaced it over the years, and on a fresh new install on another Stretch, it doesn't exist anymore.
Similar situation with the mysql.session that didn't migrate to caching_sha2_password during the upgrade, would it be fine to change his plugin without setting any password ?
+-----------+---------------+-----------------------+-------------------------------------------+
| Host | User | plugin | authentication_string |
+-----------+---------------+-----------------------+-------------------------------------------+
| localhost | mysql.session | mysql_native_password | *THISISNOTAVALIDPASSWORDTHATCANBEUSEDHERE |
+-----------+---------------+-----------------------+-------------------------------------------+
Our current setup has a manifest/site.pp that include the following for all of our modules
File {
ignore => ['.swp'],
}
However when running puppet on the client side, it still tries to push the .swp file.
Info: Using configured environment 'production'
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts
Info: Applying configuration version '1584008633'
Notice: /Stage[main]/Nginx::Abstract/File[/etc/nginx/sites-available/.amazingnameindeed.conf.swp]/ensure: current_value absent, should be file (noop)
Notice: /etc/nginx: Would have triggered 'refresh' from 1 events
Notice: Class[Nginx::Abstract]: Would have triggered 'refresh' from 1 events
Notice: Stage[main]: Would have triggered 'refresh' from 1 events
Notice: Applied catalog in 3.72 seconds
According to https://puppet.com/docs/puppet/5.5/types/file.html#file-attribute-ignore that should enable all our modules to ignore the .swp files ?
Since we've put in place a Master/Slave for our Kerberos, we've noticed that our fields doesn't get updated (Information wise)
Last password change: Fri Aug 02 10:18:08 GMT 2019
Last modified: Fri Aug 02 10:18:08 GMT 2019 (root/[email protected])
Last successful authentication: Sat Aug 03 12:35:41 GMT 2019
Last failed authentication: Wed Jul 10 12:59:28 GMT 2019
This only happened when our clients are configured as follow
[libdefaults]
default_realm = EXAMPLE.COM
forwardable = true
proxiable = true
dns_lookup_kdc = no
dns_lookup_realm = no
allow_weak_crypto = true
[realms]
EXAMPLE.COM = {
kdc = kerberos-slave.EXAMPLE.COM
admin_server = kerberos.EXAMPLE.COM
kpasswd_server = kerberos.EXAMPLE.COM
master_kdc = kerberos.EXAMPLE.COM
default_domain = EXAMPLE.COM
default_lifetime = 7d
ticket_lifetime = 7d
}
[domain_realm]
.EXAMPLE.COM = EXAMPLE.COM
EXAMPLE.COM = EXAMPLE.COM
If our clients directly use the master kerberos, our fields do get updated nicely. Would there be a way to update the fields on the Master, while querying directly from the slave?
Directly using kdc = master kerberos does update the KDC DB fields.
[libdefaults]
default_realm = EXAMPLE.COM
forwardable = true
proxiable = true
dns_lookup_kdc = no
dns_lookup_realm = no
allow_weak_crypto = true
[realms]
EXAMPLE.COM = {
kdc = kerberos.EXAMPLE.COM
admin_server = kerberos.EXAMPLE.COM
kpasswd_server = kerberos.EXAMPLE.COM
master_kdc = kerberos.EXAMPLE.COM
default_domain = EXAMPLE.COM
default_lifetime = 7d
ticket_lifetime = 7d
}
[domain_realm]
.EXAMPLE.COM = EXAMPLE.COM
EXAMPLE.COM = EXAMPLE.COM
Is it a good habit to use a ip helper address on Cisco, or any similar ip helper, when the DHCP is on the same subnet as the client/server.
We received a DL380 with 4 Gigabit Ethernet (normal CAT6), and 2 Fiber SFP+ (HPE 10Gb SR SPF+).
I've successfully managed to bond the 4 Gigabit Ethernet together, and put in place some LACP on our Cisco equipment.
I can succefully bond the 4 Gigabit Ethernet together with the following
auto bond0
iface bond0 inet dhcp
bond-mode 4
bond-primary eno1
bond-slaves eno1 eno2 eno3 eno4
bond-miimon 100
bond-downdelay 400
bond-updelay 800
According to this post it's impossible to add one of the Fiber channel to the bonding group ? Sadly, the solution provided is... 404
I'm curious if stuff have changed from now ?
Can we bond 1Gb Ethernet with 10GB SFP+ Fiber ?
I'm looking how to add the GSSAPI support into my OpenLDAP ?
Current setup
MIT Kerberos V + OpenLDAP
Kerberos bind to openldap
Able to issue kerberos tickets to my users (with kinit exampluser)
Able to ldapsearch -x uid=exampluser
Openldap side
server% ldapsearch -x -H ldapi:/// -b "" -LLL -s base -Z supportedSASLMechanisms
ldap_start_tls: Protocol error (2)
additional info: unsupported extended operation
dn:
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: EXTERNAL
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: NTLM
supportedSASLMechanisms: LOGIN
supportedSASLMechanisms: PLAIN
Client Side
client% ldapsearch uid=exampleuser
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Authentication method not supported (7)
additional info: SASL(-4): no mechanism available: Couldn't find mech GSSAPI
Client ldap.conf
#
# LDAP Defaults
#
# See ldap.conf(5) for details
# This file should be world readable but not world writable.
BASE dc=example,dc=com
URI ldap://ldap.example.com
SASL_MECH GSSAPI
Obviously, the error is clear enough to explain that my ldap request didn't find the mechanism to auth.
I've been through many tutorial, explanations, but still can't find anywhere how to "add" that mechanism.
Thanks What is SASL/GSSAPI? for all the awesome explanations.
Updated for user 473183469
I've generated a keytab just for the ldap, that I've copied in /etc/ldap/ldap.keytab, and edited the /etc/default/slapd according to https://help.ubuntu.com/community/SingleSignOn asking to uncomment and give the path to export KRB5_KTNAME=/etc/ldap/ldap.keytab
That ldap keytab was generated like that
kadmin: addprinc -randkey ldap/[email protected]
kadmin: ktadd -k ~/ldap.keytab ldap/[email protected]
I also have a /etc/krb5.keytab that was created at the beginning of the installation
kadmin.local: listprincs
[email protected]
K/[email protected]
krbtgt/[email protected]
kadmin/[email protected]
kadmin/[email protected]
kadmin/[email protected]
kadmin/[email protected]
[email protected] (also in the ldap, can issue a ticket and everything)
[email protected] (same for him)
ldap/[email protected]
The ktutil result
# ktutil
ktutil: read_kt /etc/ldap.keytab
ktutil: list
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
1 2 ldap/[email protected]
2 2 ldap/[email protected]
3 2 ldap/[email protected]
4 2 ldap/[email protected]
ktutil: read_kt /etc/krb5.keytab
ktutil: list
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
1 2 ldap/[email protected]
2 2 ldap/[email protected]
3 2 ldap/[email protected]
4 2 ldap/[email protected]
5 2 kadmin/[email protected]
6 2 kadmin/[email protected]
7 2 kadmin/[email protected]
8 2 kadmin/[email protected]
I'm currently running an openldap server on a debian machine
Distributor ID: Debian
Description: Debian GNU/Linux 8.7 (jessie)
Release: 8.7
Codename: jessie
Slapd version
@(#) $OpenLDAP: slapd (Jan 16 2016 23:00:08) $
root@chimera:/tmp/buildd/openldap-2.4.40+dfsg/debian/build/servers/slapd
I've transform the official schema into an ldif with following tutorial here
Worked perfectly my kerberos ldifs, but when I try to apply the apple.ldif, I encounter a
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "cn=apple,cn=schema,cn=config"
ldap_add: Other (e.g., implementation specific) error (80)
additional info: olcObjectClasses: AttributeType not found: "acctFlags"
So far, some blogs say that this isn't a critical attribute, and could be directly removed.
I wanted to know if that's "normal" to just remove some attributes directly from the official schema (same schema I can also get from directly some iMacs in the infrastructure) ?