Re: (ITS#8281) Syncrepl refresh failure when slapd is restarted midstream
by hyc＠symas.com
Michael Ströder wrote:
> hyc(a)symas.com wrote:
>> Michael Ströder wrote:
>>> hyc(a)symas.com wrote:
>>>> Generating a new contextCSN at startup is of questionable worth. We discussed
>>>> this a bit 'way back in 2004
>>>> http://www.openldap.org/lists/openldap-devel/200408/msg00035.html Perhaps we
>>>> should just not do it;
>>>
>>> +1
>>>
>>>> if a single-master provider starts up empty and a
>>>> consumer tries to talk to it and both have an empty cookie, the provider
>>>> should just respond "you're up to date".
>>>
>>> Why not return an error to the consumer?
>>
>> Typically if a consumer receives an error it will disconnect and retry later.
>> There's not much point making the consumer reconnect - which may be costly for
>> a TCP session. If it's a refreshAndPersist consumer, it just needs to hang on
>> and wait for some real data to arrive.
>
> Is the cost really that high compared to the rest of the initialization?
I meant "TLS" there.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7 years, 5 months
Re: (ITS#8281) Syncrepl refresh failure when slapd is restarted midstream
by michael＠stroeder.com
hyc(a)symas.com wrote:
> Michael Ströder wrote:
>> hyc(a)symas.com wrote:
>>> Generating a new contextCSN at startup is of questionable worth. We discussed
>>> this a bit 'way back in 2004
>>> http://www.openldap.org/lists/openldap-devel/200408/msg00035.html Perhaps we
>>> should just not do it;
>>
>> +1
>>
>>> if a single-master provider starts up empty and a
>>> consumer tries to talk to it and both have an empty cookie, the provider
>>> should just respond "you're up to date".
>>
>> Why not return an error to the consumer?
>
> Typically if a consumer receives an error it will disconnect and retry later.
> There's not much point making the consumer reconnect - which may be costly for
> a TCP session. If it's a refreshAndPersist consumer, it just needs to hang on
> and wait for some real data to arrive.
Is the cost really that high compared to the rest of the initialization?
>> Does the provider know whether it's running as single-master?
>
> Generally yes. A single-master setup has serverID=0.
Hmm, this introduces more semantics on serverID. I have some doubts about
corner-cases.
Maybe I misunderstood but IMO the issue was about changing a provider to a MMR
replica which would need serverID!=0 anyway.
Ciao, Michael.
7 years, 5 months
Re: (ITS#8281) Syncrepl refresh failure when slapd is restarted midstream
by hyc＠symas.com
Michael Ströder wrote:
> hyc(a)symas.com wrote:
>> Generating a new contextCSN at startup is of questionable worth. We discussed
>> this a bit 'way back in 2004
>> http://www.openldap.org/lists/openldap-devel/200408/msg00035.html Perhaps we
>> should just not do it;
>
> +1
>
>> if a single-master provider starts up empty and a
>> consumer tries to talk to it and both have an empty cookie, the provider
>> should just respond "you're up to date".
>
> Why not return an error to the consumer?
Typically if a consumer receives an error it will disconnect and retry later.
There's not much point making the consumer reconnect - which may be costly for
a TCP session. If it's a refreshAndPersist consumer, it just needs to hang on
and wait for some real data to arrive.
> Does the provider know whether it's running as single-master?
Generally yes. A single-master setup has serverID=0.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7 years, 5 months
Re: (ITS#8281) Syncrepl refresh failure when slapd is restarted midstream
by michael＠stroeder.com
This is a cryptographically signed message in MIME format.
--------------ms040207060304010508030608
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
hyc(a)symas.com wrote:
> Generating a new contextCSN at startup is of questionable worth. We dis=
cussed=20
> this a bit 'way back in 2004=20
> http://www.openldap.org/lists/openldap-devel/200408/msg00035.html Perha=
ps we=20
> should just not do it;
+1
> if a single-master provider starts up empty and a=20
> consumer tries to talk to it and both have an empty cookie, the provide=
r=20
> should just respond "you're up to date".
Why not return an error to the consumer?
Does the provider know whether it's running as single-master?
Ciao, Michael.
--------------ms040207060304010508030608
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DGYwggYqMIIFEqADAgECAgMPVg4wDQYJKoZIhvcNAQELBQAwgYwxCzAJBgNVBAYTAklMMRYw
FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp
Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQTAeFw0xNTA5MTAxNjMwMTdaFw0xNjA5MTAxNDA3NTBaMEQxHTAb
BgNVBAMMFG1pY2hhZWxAc3Ryb2VkZXIuY29tMSMwIQYJKoZIhvcNAQkBFhRtaWNoYWVsQHN0
cm9lZGVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ3ulgRkFW/ozuAX
8HwDmP7ifGF09KbLcAEVVjS013fTAlEzq0TJVcMXx/57LqdWtelCi35YvCzXHURuZl6hpUlR
+yOR1sev9xP2NfEJHQKUfs435wN6xFmdg/LI+ydlJ/exc3XxZVnb994vtJOlQh1HgXJvCORp
9d359fQQMY5N71TiQs0rcn8SNUBLZYHom1U2g2oEHN/QFNf2noxfXdPxTWeeeR0EuhH1Yy/0
AE2JZk2VmFW6VZYjEPoXUOfRizEzSM6HjyG347RnFd5Zh5vquxN609Z2iSg1Txuvd/eLSSuu
9sxLfw/5Qq4Xd/vhNVTrvG8d4M9L54orRVdFwmsCAwEAAaOCAtowggLWMAkGA1UdEwQCMAAw
CwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU
ubJgGvVtleGfzm7tjClKT2uUcB4wHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw
HwYDVR0RBBgwFoEUbWljaGFlbEBzdHJvZWRlci5jb20wggFMBgNVHSAEggFDMIIBPzCCATsG
CysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v
cG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB
dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg
dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g
Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8w
LTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYB
BQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9j
bGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9j
ZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vMA0GCSqGSIb3DQEBCwUAA4IBAQAv5aQr1I7ZAg4VJJtaPIi61v/v0v9j
Hs/Gl695n7shMeZx/H5F6EAwma0MWIWv1H9mtFcGhXiwr55SR1xMffy+C2Q5byyVcVKmrC+E
vP1Ke+VnJ6v/l3JV5zPQf38XdCvYQACHFIODnVmD5JI59TWzS5ReudfTf60kQeNoRTZH15el
8hORNOzkoGiV70Kuuw7pCOf0ncjshttJE3NetXa2f4rTsCC5UNrMqhF8Y6NALa3m/zzCK1+i
nvukFQPBU3+NFeNcrpp2nroEutsl3ftkcw6jAvQvTGEIw6AO13fgujtge+kxyoF2RuCSsEmT
jmyZ7QweLwfmuU70umVTM8HUMIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQsw
CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp
Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkG
A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp
dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJp
bWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESi
p7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9f
tTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsW
oTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/
43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IB
rTCCAakwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc
4NrLAVx8fpY1TvLUuFGCMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsG
AQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0G
CCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQw
UjAnoCWgI4YhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRw
Oi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcB
AgEwZjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0
BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjAN
BgkqhkiG9w0BAQUFAAOCAgEACoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHb
WNaPeQn3oBSU8KgQZn/Kck1JxbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4
OxK9QPoSjCMxM3HbkZCDJgnlE8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0
KAkXCzeQNLeA5LlYUzFyM7kPAp8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL0
4qYK/zu+Qg1Bw0RwgigVZs/0c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0
IFiNu9IPuTGAPBn4CPxD0+Ru8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6
fDEPme+1Nbi+03pVjuZQKbGwKJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVt
jYsv0L1TSm2+NwON58tO+pIVzu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm4
8ZCYfAWLb/Xj7F5JQMbZvCexglAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BI
XRsF1du4qESm4/3CKuyUV7p9DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIB
ATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29t
IENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMPVg4wDQYJYIZIAWUD
BAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1
MTAyMzA2MTIxMlowLwYJKoZIhvcNAQkEMSIEIJ1bOIoAw+/k1uuBzuvpmtdm9eMbylsfYVQJ
+up45kF5MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq
hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI
hvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg
Q2xpZW50IENBAgMPVg4wgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEW
MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm
aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy
bWVkaWF0ZSBDbGllbnQgQ0ECAw9WDjANBgkqhkiG9w0BAQEFAASCAQBMHz+sfRalN5J1irhn
M18JNKr1bgzkIZSQEXt1Qmpfn35F8KsflZ38NBUKlX/N+WuyyuV3FnGCge3gY3w9aerdQ0W6
fGH77h6KZdNcFvYA8iAqVqn1GmxVqI5jovL9VuPHbfVHpqkdCOFMrhryefvnMUg25M6iPyxj
Bu6KVnLh+JXZn1kpxqhkl7hFdLfLbXQL9pNLmw11L8UjHCNffvvfzBKNjxn4d3Ube4YV/etz
PL41Ceg7/uTx8P6qI3Hhh2hVBRVaO3J84GLLOnoHIrEXnfUhkRNM1ST30MNWgtN3ng0+LCDE
oBXKt5qEM0g9MWVtZpvRzsEj+DhAh+wzkfhcAAAAAAAA
--------------ms040207060304010508030608--
7 years, 5 months
Re: (ITS#8281) Syncrepl refresh failure when slapd is restarted midstream
by hyc＠symas.com
quanah(a)openldap.org wrote:
> Full_Name: Quanah Gibson-Mount
> Version: RE24 Sept 11, 2015
> OS: Linux 2.6
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (75.111.52.177)
>
>
> Seeing a scenario where if slapd is stopped on a new MMR node while a full
> REFRESH is occurring, the state of that refresh is not tracked, and the wrong
> CSN value is stored.
> This dataset has 15,000 users. We see it get up to user 625:
>
> Oct 20 16:13:09 q2 slapd[18724]: syncrepl_entry: rid=100 be_search (0)
> Oct 20 16:13:09 q2 slapd[18724]: syncrepl_entry: rid=100
> uid=user625,ou=people,dc=q1,dc=aon,dc=zimbraview,dc=com
> Oct 20 16:13:09 q2 slapd[18724]: slap_queue_csn: queueing 0x44c7e30
> 20151020185526.862768Z#000000#000#000000
> Oct 20 16:13:09 q2 slapd[18724]: slap_graduate_commit_csn: removing 0x44c87c0
> 20151020185526.862768Z#000000#000#000000
> Oct 20 16:13:09 q2 slapd[18724]: syncrepl_entry: rid=100 be_add
> uid=user625,ou=people,dc=q2C2Cdc=aon,dc=zimbraview,dc=com (0)
> Oct 20 16:13:09 q2 slapd[18724]: slapd stopped.
>
>
> Then when slapd is restarted:
>
> Oct 20 16:13:16 q2 slapd[18970]: do_syncrep2: rid=100
> cookie=rid=100,sid=001,csn=20151020201231.263989Z#000000#001#000000
> Oct 20 16:13:16 q2 slapd[18970]: sp_p_queue_csn: queueing 0x309dfd8
> 20151020201231.263989Z#000000#001#000000
> Oct 20 16:13:16 q2 slapd[18970]: slap_queue_csn: queueing 0x5054008
> 20151020201231.263989Z#000000#001#000000
> Oct 20 16:13:16 q2 slapd[18970]: slap_graduate_commit_csn: removing 0x49353c0
> 20151020201231.263989Z#000000#001#000000
> Oct 20 16:13:16 q2 slapd[18970]: slap_graduate_commit_csn: removing 0x4935060
> 20151020201231.263989Z#000000#001#000000
> Oct 20 16:13:16 q2 slapd[18970]: syncrepl_message_to_op: rid=100 be_add
> cn=q2.aon.zimbraview.com,cn=servers,cn=zimbra (0)
>
> which causes it to skip the other 14,000+ users.
After investigating the server setup, there are a few problems here.
The new server was being configured with sid=001 which was already assigned to
the original master. That's clearly going to screw things up.
Aside from that, the new server was converted to MMR using dynamic config and
we have a sequencing problem - it adds the syncprov overlay first, and then
adds the syncrepl config. This is actually the only safe order, since the
consumer will start as soon as it's added and syncprov will already be in
place, ready to propagate changes as needed.
But .. syncprov does a check in syncprov_db_open() to decide whether it should
generate an initial contextCSN on a new DB. This step is ignored if the
backend is configured for MMR (and must be ignored). The problem is that this
node *will be* configured for MMR, but it isn't yet, because the consumer
hasn't been dynamically configured yet. So syncprov generates its own
contextCSN, which is checkpointed on shutdown. The real contextCSN from the
master hasn't been received yet since the refresh is still in progress when
the server is stopped, so on next restart this consumer will present its
generated contextCSN, which is newer than the original master's, and so it
won't resume refreshing from where it left off.
Generating a new contextCSN at startup is of questionable worth. We discussed
this a bit 'way back in 2004
http://www.openldap.org/lists/openldap-devel/200408/msg00035.html Perhaps we
should just not do it; if a single-master provider starts up empty and a
consumer tries to talk to it and both have an empty cookie, the provider
should just respond "you're up to date".
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7 years, 5 months
Re: (ITS#8287) ldap server address book
by michael＠stroeder.com
ikshafi(a)yahoo.com wrote:
> Full_Name: sifat ara nil
> Version: 2.4.39
> OS: centros
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (103.230.63.94)
>
>
> I have create a Ldap server for Email address book purpose .Its running well and
> i am able to search by name . But it's not showing all address in microsoft
> outlook address book without search . how can i make it visible .
The ITS is for reporting bugs only.
You can ask usage questions on the openldap-technical mailing list.
For Outlook try to search for suitable LDAP attribute mappings.
It has been discussed numerous times before.
Ciao, Michael.
7 years, 5 months
(ITS#8287) ldap server address book
by ikshafi＠yahoo.com
Full_Name: sifat ara nil
Version: 2.4.39
OS: centros
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (103.230.63.94)
I have create a Ldap server for Email address book purpose .Its running well and
i am able to search by name . But it's not showing all address in microsoft
outlook address book without search . how can i make it visible .
7 years, 5 months
Re: (ITS#8285) RFE slapo-ppolicy: fall back to createTimestamp
by hyc＠symas.com
michael(a)stroeder.com wrote:
> Full_Name: Michael Str.der
> Version:
> OS:
> URL:
> Submission from: (NULL) (213.240.180.113)
>
>
> If pwdMaxAge is set in a pwdPolicy entry but the user's entry does not contain
> pwdChangedTime attribute createTimestamp should be used instead to determine
> whether password is expired or not.
>
> The case above can happen if there are already existing entries with
> userPassword and slapo-ppolicy gets installed and activated later.
>
No. The spec says for pwdChangedTime "If this attribute does not exist, the
password will never expire."
Closing this ITS.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7 years, 5 months
(ITS#8285) RFE slapo-ppolicy: fall back to createTimestamp
by michael＠stroeder.com
Full_Name: Michael Str.der
Version:
OS:
URL:
Submission from: (NULL) (213.240.180.113)
If pwdMaxAge is set in a pwdPolicy entry but the user's entry does not contain
pwdChangedTime attribute createTimestamp should be used instead to determine
whether password is expired or not.
The case above can happen if there are already existing entries with
userPassword and slapo-ppolicy gets installed and activated later.
7 years, 5 months
