[389-users] Re: ip address based aci

2017-11-16 Thread William Brown
On Mon, 2017-11-13 at 10:34 +0100, Jan Kowalsky wrote:
> Hi William,
> 
> thanks a lot for clearing.

Sorry for the very late response! I have been quite busy :( 

> 
> Am 13.11.2017 um 00:42 schrieb William Brown:
> > On Sun, 2017-11-12 at 23:06 +0100, Jan Kowalsky wrote:
> > > On some comments I read that it's generally discouraged to use
> > > aci's
> > > with a "not" logic like:
> > > 
> > >  ip != 10.0.0.*
> > > 
> > > or something like this.
> > > 
> > 
> > The != is only an issue for targetattr, because if you do:
> > 
> > targetattr != sn
> > 
> > Then this includes all system attributes like nsACcountlock and
> > resource limit types etc. 
> > 
> > IP addr != is fine :) 
> > > As long as I understood, I have to define aci's for every base dn
> > > separately if I running multiple databases. Is there any way to
> > > define
> > > this for the whole server?
> > 
> > If you have the databases nested IE:
> > 
> > dc=example,dc=com
> > ou=foo,dc=example,dc=com
> > 
> > And in the mapping tree these are marked as "parent", then the aci
> > of
> > dc=example,dc=com should apply to ou=foo too. 
> 
> ok. So for me it doesn't work. The databases are completely
> separeted.

Then you can't share aci's sorry :( This is just a reality of how our
aci's operate. 

> 
> > Generally, I would look at:
> > 
> > https://research.google.com/pubs/pub43231.html
> > 
> > IP address based security is not a good control: You should be
> > using
> > other factors and information to provide access I think. You could
> > limit admins to using TLS user certs for identity rather than
> > passwords, using minssf rules, longer password policy, etc.
> 
> The ip based access control in my setting is only to give a
> additionally
> control beside the firewall. The Directory should not to be
> accessible
> from public internet at all. But for the case there is any error on
> firewalling I want to protect the whole directory. Other access
> rights
> are more granular.

Why not limit this based on iptables *and* your routers instead? That
would be a more effective control I think than ip based access
controls.

Additionally, another option is remove anonymous binds (or heavily
limit anonymous access), and use service accounts for applications to
read attributes that they require? This could be more effective than IP
controls, because when you think about an attacker, they don't just go
"from internet to ldap". They'll have poped a box on your network
internally, so the exfiltration route is:

ds -> poped internal box -> internet.

So your internet controls won't help here, because your ds is talking
*internally*. Better option is limit based on service accounts and
privilege than IP. 


I really hope this advice helps,


> 
> Regards
> Jan
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave@lists.fedoraproject.o
> rg
-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org


[389-users] performance tuning

2017-11-16 Thread Sergei Gerasenko
Hi,

I’ve been trying to estimate how optimal our settings are. I’ve read about the 
cn=monitor section and I see that there are several paths that have cn=monitor:

dn: cn=monitor,cn=ldbm database,cn=plugins,cn=config
dn: cn=monitor,cn=changelog,cn=ldbm database,cn=plugins,cn=config
dn: cn=monitor,cn=ipaca,cn=ldbm database,cn=plugins,cn=config
dn: cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config

First question, what’s the difference between them?

Here’s the output of ldapsearch for the 1st and 4th variants. Does anybody see 
something abnormal?


# => 'cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config’


dn: cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
cn: monitor
objectClass: top
objectClass: extensibleObject
database: ldbm database
readonly: 0
entrycachehits: 176959465
entrycachetries: 262445216
entrycachehitratio: 67
currententrycachesize: 10479044
maxentrycachesize: 10485760
currententrycachecount: 1409
maxentrycachecount: -1
dncachehits: 80627325
dncachetries: 80647850
dncachehitratio: 99
currentdncachesize: 1013607
maxdncachesize: 10485760
currentdncachecount: 9375
maxdncachecount: -1
normalizeddncachetries: 634018073
normalizeddncachehits: 633931903
normalizeddncachemisses: 86170
normalizeddncachehitratio: 99
currentnormalizeddncachesize: 19244372
maxnormalizeddncachesize: 20971520
currentnormalizeddncachecount: 86170
dbfilename-0: userRoot/nsds5ReplConflict.db
dbfilecachehit-0: 0
dbfilecachemiss-0: 3
dbfilepagein-0: 3
dbfilepageout-0: 0
dbfilename-1: userRoot/memberOf.db
dbfilecachehit-1: 188045
dbfilecachemiss-1: 4684
dbfilepagein-1: 4684
dbfilepageout-1: 1325
dbfilename-4: userRoot/cn.db
dbfilecachehit-4: 234345675
dbfilecachemiss-4: 69406
dbfilepagein-4: 69406
dbfilepageout-4: 6967
dbfilename-7: userRoot/numsubordinates.db
dbfilecachehit-7: 64
dbfilecachemiss-7: 143
dbfilepagein-7: 143
dbfilepageout-7: 148
dbfilename-8: userRoot/uid.db
dbfilecachehit-8: 23978617
dbfilecachemiss-8: 15927
dbfilepagein-8: 15927
dbfilepageout-8: 38
dbfilename-9: userRoot/fqdn.db
dbfilecachehit-9: 1719355
dbfilecachemiss-9: 187947
dbfilepagein-9: 187947
dbfilepageout-9: 440
dbfilename-10: userRoot/memberallowcmd.db
dbfilecachehit-10: 1615
dbfilecachemiss-10: 492
dbfilepagein-10: 492
dbfilepageout-10: 0
dbfilename-11: userRoot/krbPrincipalName.db
dbfilecachehit-11: 25458823
dbfilecachemiss-11: 484795
dbfilepagein-11: 484789
dbfilepageout-11: 9526
dbfilename-12: userRoot/member.db
dbfilecachehit-12: 114136
dbfilecachemiss-12: 13041
dbfilepagein-12: 13041
dbfilepageout-12: 11865
dbfilename-13: userRoot/memberUser.db
dbfilecachehit-13: 27275
dbfilecachemiss-13: 849
dbfilepagein-13: 849
dbfilepageout-13: 306
dbfilename-14: userRoot/nsuniqueid.db
dbfilecachehit-14: 95501
dbfilecachemiss-14: 11980
dbfilepagein-14: 11980
dbfilepageout-14: 181
dbfilename-16: userRoot/mail.db
dbfilecachehit-16: 196
dbfilecachemiss-16: 209
dbfilepagein-16: 209
dbfilepageout-16: 203
dbfilename-17: userRoot/parentid.db
dbfilecachehit-17: 14494
dbfilecachemiss-17: 2956
dbfilepagein-17: 2956
dbfilepageout-17: 432
dbfilename-19: userRoot/givenName.db
dbfilecachehit-19: 42
dbfilecachemiss-19: 44
dbfilepagein-19: 44
dbfilepageout-19: 38
dbfilename-20: userRoot/uidnumber.db
dbfilecachehit-20: 711150
dbfilecachemiss-20: 12493
dbfilepagein-20: 12493
dbfilepageout-20: 5
dbfilename-21: userRoot/ipauniqueid.db
dbfilecachehit-21: 38595230
dbfilecachemiss-21: 406501
dbfilepagein-21: 406501
dbfilepageout-21: 169
dbfilename-22: userRoot/ipasudorunasgroup.db
dbfilecachehit-22: 812
dbfilecachemiss-22: 242
dbfilepagein-22: 242
dbfilepageout-22: 0
dbfilename-23: userRoot/objectclass.db
dbfilecachehit-23: 1027902225
dbfilecachemiss-23: 49163
dbfilepagein-23: 49163
dbfilepageout-23: 3332
dbfilename-24: userRoot/memberdenycmd.db
dbfilecachehit-24: 803
dbfilecachemiss-24: 251
dbfilepagein-24: 251
dbfilepageout-24: 0
dbfilename-25: userRoot/ipakrbprincipalalias.db
dbfilecachehit-25: 7957213
dbfilecachemiss-25: 226
dbfilepagein-25: 226
dbfilepageout-25: 0
dbfilename-29: userRoot/id2entry.db
dbfilecachehit-29: 255566500
dbfilecachemiss-29: 9612037
dbfilepagein-29: 9612016
dbfilepageout-29: 54967
dbfilename-30: userRoot/ancestorid.db
dbfilecachehit-30: 21700375
dbfilecachemiss-30: 78004
dbfilepagein-30: 78004
dbfilepageout-30: 1112
dbfilename-31: userRoot/aci.db
dbfilecachehit-31: 1
dbfilecachemiss-31: 2
dbfilepagein-31: 2
dbfilepageout-31: 0
dbfilename-32: userRoot/ipasudorunas.db
dbfilecachehit-32: 1875
dbfilecachemiss-32: 512
dbfilepagein-32: 512
dbfilepageout-32: 18
dbfilename-33: userRoot/nscpEntryDN.db
dbfilecachehit-33: 61
dbfilecachemiss-33: 68
dbfilepagein-33: 68
dbfilepageout-33: 69
dbfilename-35: userRoot/sn.db
dbfilecachehit-35: 46
dbfilecachemiss-35: 52
dbfilepagein-35: 52
dbfilepageout-35: 46
dbfilename-36: userRoot/displayname.d

[389-users] Re: performance tuning

2017-11-16 Thread William Brown
On Thu, 2017-11-16 at 21:00 -0600, Sergei Gerasenko wrote:
> Hi,
> 
> I’ve been trying to estimate how optimal our settings are. I’ve read
> about the cn=monitor section and I see that there are several paths
> that have cn=monitor:

These are all monitors for each database backend. So you have: 

> 
> dn: cn=monitor,cn=ldbm database,cn=plugins,cn=config
^ This monitors the general BDB performance.

> dn: cn=monitor,cn=changelog,cn=ldbm database,cn=plugins,cn=config
> dn: cn=monitor,cn=ipaca,cn=ldbm database,cn=plugins,cn=config
> dn: cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
> 

^ These are monitors of unique suffixes and their indexes and other
content like entrycaches that are per backend. 

So each of them can reveal different info.

BDB can show you about the interaction between DS and the BDB on disk.
So this can have some IO related impact for *all* backends. 

Then each backend monitor can help you understand the performance of
indexes, entry cache and others. So let me help interpret yours:


> First question, what’s the difference between them?
> 
> Here’s the output of ldapsearch for the 1st and 4th variants. Does
> anybody see something abnormal?
> 
> ---
> -
> # => 'cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config’
> ---
> -
> 
> dn: cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
> cn: monitor
> objectClass: top
> objectClass: extensibleObject
> database: ldbm database
> readonly: 0
> entrycachehits: 176959465
> entrycachetries: 262445216
> entrycachehitratio: 67

^ this 5 is super important. This is saying you have only hit 67% of
the time. You really want this to be 85% or higher, else you are
constantly importing/evicting from the entry cache. Every eviction and
inclusion is costly as you have to-reread id2entry which is io
intensive.

I'd recommend increasing your entry cache size by double at a guess,
but I'd want to see your /proc/meminfo and /proc/cpuinfo to advise
properly. I'd also need to see your ds version and userroot config to
really advise what changes to make. 


> currententrycachesize: 10479044
> maxentrycachesize: 10485760
> currententrycachecount: 1409
> maxentrycachecount: -1
> dncachehits: 80627325
> dncachetries: 80647850
> dncachehitratio: 99

This number is good, what you want to see. 

> currentdncachesize: 1013607
> maxdncachesize: 10485760
> currentdncachecount: 9375
> maxdncachecount: -1
> normalizeddncachetries: 634018073
> normalizeddncachehits: 633931903
> normalizeddncachemisses: 86170
> normalizeddncachehitratio: 99

Again, also good, 

> currentnormalizeddncachesize: 19244372
> maxnormalizeddncachesize: 20971520
> currentnormalizeddncachecount: 86170
> dbfilename-0: userRoot/nsds5ReplConflict.db
> dbfilecachehit-0: 0
> dbfilecachemiss-0: 3
> dbfilepagein-0: 3
> dbfilepageout-0: 0
> dbfilename-1: userRoot/memberOf.db
> dbfilecachehit-1: 188045
> dbfilecachemiss-1: 4684
> dbfilepagein-1: 4684
> dbfilepageout-1: 1325
> dbfilename-4: userRoot/cn.db
> dbfilecachehit-4: 234345675
> dbfilecachemiss-4: 69406
> dbfilepagein-4: 69406
> dbfilepageout-4: 6967
> dbfilename-7: userRoot/numsubordinates.db
> dbfilecachehit-7: 64
> dbfilecachemiss-7: 143
> dbfilepagein-7: 143
> dbfilepageout-7: 148
> dbfilename-8: userRoot/uid.db
> dbfilecachehit-8: 23978617
> dbfilecachemiss-8: 15927
> dbfilepagein-8: 15927
> dbfilepageout-8: 38
> dbfilename-9: userRoot/fqdn.db
> dbfilecachehit-9: 1719355
> dbfilecachemiss-9: 187947
> dbfilepagein-9: 187947
> dbfilepageout-9: 440
> dbfilename-10: userRoot/memberallowcmd.db
> dbfilecachehit-10: 1615
> dbfilecachemiss-10: 492
> dbfilepagein-10: 492
> dbfilepageout-10: 0
> dbfilename-11: userRoot/krbPrincipalName.db
> dbfilecachehit-11: 25458823
> dbfilecachemiss-11: 484795
> dbfilepagein-11: 484789
> dbfilepageout-11: 9526
> dbfilename-12: userRoot/member.db
> dbfilecachehit-12: 114136
> dbfilecachemiss-12: 13041
> dbfilepagein-12: 13041
> dbfilepageout-12: 11865
> dbfilename-13: userRoot/memberUser.db
> dbfilecachehit-13: 27275
> dbfilecachemiss-13: 849
> dbfilepagein-13: 849
> dbfilepageout-13: 306
> dbfilename-14: userRoot/nsuniqueid.db
> dbfilecachehit-14: 95501
> dbfilecachemiss-14: 11980
> dbfilepagein-14: 11980
> dbfilepageout-14: 181
> dbfilename-16: userRoot/mail.db
> dbfilecachehit-16: 196
> dbfilecachemiss-16: 209
> dbfilepagein-16: 209
> dbfilepageout-16: 203
> dbfilename-17: userRoot/parentid.db
> dbfilecachehit-17: 14494
> dbfilecachemiss-17: 2956
> dbfilepagein-17: 2956
> dbfilepageout-17: 432
> dbfilename-19: userRoot/givenName.db
> dbfilecachehit-19: 42
> dbfilecachemiss-19: 44
> dbfilepagein-19: 44
> dbfilepageout-19: 38
> dbfilename-20: userRoot/uidnumber.db
> dbfilecachehit-20: 711150
> dbfilecachemiss-20: 12493
> dbfilepagein-20: 12493
> dbfilepageout-20: 5
> dbfilename-21: userRoot/ipauniqueid.db

[389-users] Re: performance tuning

2017-11-16 Thread Sergei Gerasenko
Hi William,Thanks much for the quick response! This is super helpful. I’m attaching my cpu and meminfo info.dn: cn=monitor,cn=ldbm database,cn=plugins,cn=config^ This monitors the general BDB performance.Got it.dn: cn=monitor,cn=changelog,cn=ldbm database,cn=plugins,cn=configdn: cn=monitor,cn=ipaca,cn=ldbm database,cn=plugins,cn=configdn: cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config^ These are monitors of unique suffixes and their indexes and othercontent like entrycaches that are per backend. Cool. One question I’ve been meaning to ask — what’s under userRoot in general?entrycachehitratio: 67^ this 5 is super important. This is saying you have only hit 67% ofthe time. You really want this to be 85% or higher, else you areconstantly importing/evicting from the entry cache. Every eviction andinclusion is costly as you have to-reread id2entry which is iointensive.I'd recommend increasing your entry cache size by double at a guess,but I'd want to see your /proc/meminfo and /proc/cpuinfo to adviseproperly. I'd also need to see your ds version and userroot config toreally advise what changes to make. Great info! I think we have plenty of RAM (64G) to make any adjustment we want.I’ve also heard of nsslapd-cachememsize — what does that control?Thanks so much, William!!Sergeicat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 63
model name  : Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz
stepping: 2
microcode   : 0x38
cpu MHz : 2799.976
cache size  : 20480 KB
physical id : 0
siblings: 16
core id : 0
cpu cores   : 8
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 15
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss h
t tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts 
rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu
pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm 
pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadl
ine_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb pln pts dtherm 
tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_ad
just bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc cqm_occup_llc
bogomips: 5194.03
clflush size: 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 63
model name  : Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz
stepping: 2
microcode   : 0x38
cpu MHz : 2799.976
cache size  : 20480 KB
physical id : 1
siblings: 16
core id : 0
cpu cores   : 8
apicid  : 16
initial apicid  : 16
fpu : yes
fpu_exception   : yes
cpuid level : 15
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss h
t tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts 
rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu
pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm 
pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadl
ine_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb pln pts dtherm 
tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_ad
just bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc cqm_occup_llc
bogomips: 5198.12
clflush size: 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

processor   : 2
vendor_id   : GenuineIntel
cpu family  : 6
model   : 63
model name  : Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz
stepping: 2
microcode   : 0x38
cpu MHz : 2799.976
cache size  : 20480 KB
physical id : 0
siblings: 16
core id : 1
cpu cores   : 8
apicid  : 2
initial apicid  : 2
fpu : yes
fpu_exception   : yes
cpuid level : 15
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss h
t tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts 
rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu
pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm 
pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadl
ine_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb pln pts dtherm 
tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_ad
just bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc cqm_occup_llc
bogomips: 5194.03
clflush size: 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

processor   : 3
vendor_id   : GenuineIntel
cpu family  : 6
model   : 63
model n