Closed marcoverl closed 9 years ago
enolfc
commented
9 years ago Hi,
you can remove apel-ssm-openstack and replace the two cron jobs with a single one that invokes caso-extract, there is no "push" needed.
The ssmsend in cron will still be needed, that's what sends records to the accounting portal.
Cheers, Enol.
marcoverl
commented
9 years ago now i get this ssl error, any hint?
[apel@egi-cloud ~]$ /home/apel/.virtualenvs/caso/bin/caso-extract
2015-01-27 19:01:31.037 1521 CRITICAL caso [-] SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)
2015-01-27 19:01:31.037 1521 TRACE caso Traceback (most recent call last):
2015-01-27 19:01:31.037 1521 TRACE caso File "/home/apel/.virtualenvs/caso/bin/caso-extract", line 10, in
feyzaeryol
commented
9 years ago Hi,
I am taking the same certificate verify failed error on my installation. Do we need to set true the insecure parameter in caso.conf?
Cheers,
--feyza
alvarolopez
commented
9 years ago No, you shouldn't use the insecure flag in a production environment.
This is not a cASO problem, but a problem with the installation that cASO is using. The SSL error is caused by the requests module when it is use by any of the OpenStack clients. This is due to the fact that it cannot verify the server's certificate because it is not contained in the CA bundle. This will happen for all the OpenStack clients, not only for cASO.
/etc/ssl/certs/ca-certificates.crt from the ca-certificates package./etc/pki/tls/certs/ca-bundle.crt also from the ca-certificates package.pip) python-requests uses its own vendorized CA bundle, located in the distribution directory (i.e. requests/cacert.pem).In either case, it is needed to add tha CA that signed the host's certificates to the trusted CA bundle that requests is using. In the case of the system-wide bundles, you should refer to the documentation of those packages. In the case of using the requests' vendorized CA bundle, I guess it is enough to append the correct certificates to the end of the cacert.pem file.
@marcoverl, you are in the later case (you have your own installation in /home/apel/.virtualenvs/caso/lib/python2.7/site-packages/requests/) so you have to add the CA certificate corresponding to your host's certificate to the cacert.pem file bundled with your requests installation.
@feyzaeryol I do not know the details of your installation, but I hope that the information above helps you.
feyzaeryol
commented
9 years ago Hi Alvaro,
This solves my problem. Now it is works without any error.
Cheers,
--feyza
marcoverl
commented
9 years ago ok, fixed the issue with the cert bundle, now i get some issue related to keystone users:
[apel@egi-cloud ~]$ /home/apel/.virtualenvs/caso/bin/caso-extract
2015-01-28 11:48:30.480 28928 CRITICAL caso [-] AttributeError: username
2015-01-28 11:48:30.480 28928 TRACE caso Traceback (most recent call last):
2015-01-28 11:48:30.480 28928 TRACE caso File "/home/apel/.virtualenvs/caso/bin/caso-extract", line 10, in
alvarolopez
commented
9 years ago This was already solved in #11, please update caso to 0.1.2.
marcoverl
commented
9 years ago ok, i've updated to 0.1.2, but now i have auth. issues, even if everything seems ok in the caso.conf, and OS commands works for the OS accounting user as expected from the command line.
(caso)[apel@egi-cloud ~]$ caso-extract -d -v
2015-01-31 17:54:04.748 15670 CRITICAL caso [-] Unauthorized: The request you have made requires authentication. (HTTP 401)
2015-01-31 17:54:04.748 15670 TRACE caso Traceback (most recent call last):
2015-01-31 17:54:04.748 15670 TRACE caso File "/home/apel/.virtualenvs/caso/bin/caso-extract", line 10, in
alvarolopez
commented
9 years ago Almost nothing has changed from 0.1.1 to 0.1.2, so this should not be because of the update (the only relevant change was the fix for #11 (git diff 0.1.1 0.1.2). Are you sure that you are using the correct file?
In https://github.com/IFCA/caso/issues/15#issuecomment-71815128 you were already contacting nova (it failed loading the users from Keystone), now you are not able to contact it again, and that code has not changed.
marcoverl
commented
9 years ago Hi, i got some progress if i run caso-extract as root instead as apel (i am talking about linux user here). But still end with an auth error:
(caso)[root@egi-cloud]# caso-extract --version
0.1.2
(caso)[root@egi-cloud]# caso-extract -d -v
2015-02-02 16:26:55.317 23343 DEBUG keystoneclient.auth.identity.v2 [-] Making authentication request to https://egi-cloud.pd.infn.it:35357/v2.0/tokens get_auth_ref /root/.virtualenvs/caso/lib/python2.7/site-packages/keystoneclient/auth/identity/v2.py:76
2015-02-02 16:26:55.498 23343 DEBUG iso8601.iso8601 [-] Parsed 2015-02-03T15:26:55Z into {'tz_sign': None, 'second_fraction': None, 'hour': u'15', 'daydash': u'03', 'tz_hour': None, 'month': None, 'timezone': u'Z', 'second': u'55', 'tz_minute': None, 'year': u'2015', 'separator': u'T', 'monthdash': u'02', 'day': None, 'minute': u'26'} with default timezone <iso8601.iso8601.Utc object at 0x7f9bea76fd50> parse_date /root/.virtualenvs/caso/lib/python2.7/site-packages/iso8601/iso8601.py:184
2015-02-02 16:26:55.499 23343 DEBUG iso8601.iso8601 [-] Got u'2015' for 'year' with default None to_int /root/.virtualenvs/caso/lib/python2.7/site-packages/iso8601/iso8601.py:140
2015-02-02 16:26:55.499 23343 DEBUG iso8601.iso8601 [-] Got u'02' for 'monthdash' with default 1 to_int /root/.virtualenvs/caso/lib/python2.7/site-packages/iso8601/iso8601.py:140
2015-02-02 16:26:55.499 23343 DEBUG iso8601.iso8601 [-] Got 2 for 'month' with default 2 to_int /root/.virtualenvs/caso/lib/python2.7/site-packages/iso8601/iso8601.py:140
2015-02-02 16:26:55.499 23343 DEBUG iso8601.iso8601 [-] Got u'03' for 'daydash' with default 1 to_int /root/.virtualenvs/caso/lib/python2.7/site-packages/iso8601/iso8601.py:140
2015-02-02 16:26:55.499 23343 DEBUG iso8601.iso8601 [-] Got 3 for 'day' with default 3 to_int /root/.virtualenvs/caso/lib/python2.7/site-packages/iso8601/iso8601.py:140
2015-02-02 16:26:55.499 23343 DEBUG iso8601.iso8601 [-] Got u'15' for 'hour' with default None to_int /root/.virtualenvs/caso/lib/python2.7/site-packages/iso8601/iso8601.py:140
2015-02-02 16:26:55.499 23343 DEBUG iso8601.iso8601 [-] Got u'26' for 'minute' with default None to_int /root/.virtualenvs/caso/lib/python2.7/site-packages/iso8601/iso8601.py:140
2015-02-02 16:26:55.500 23343 DEBUG iso8601.iso8601 [-] Got u'55' for 'second' with default None to_int /root/.virtualenvs/caso/lib/python2.7/site-packages/iso8601/iso8601.py:140
2015-02-02 16:26:55.500 23343 DEBUG keystoneclient.auth.identity.v2 [-] Making authentication request to https://egi-cloud.pd.infn.it:35357/v2.0/tokens get_auth_ref /root/.virtualenvs/caso/lib/python2.7/site-packages/keystoneclient/auth/identity/v2.py:76
2015-02-02 16:26:55.654 23343 DEBUG iso8601.iso8601 [-] Parsed 2015-02-03T15:26:55Z into {'tz_sign': None, 'second_fraction': None, 'hour': u'15', 'daydash': u'03', 'tz_hour': None, 'month': None, 'timezone': u'Z', 'second': u'55', 'tz_minute': None, 'year': u'2015', 'separator': u'T', 'monthdash': u'02', 'day': None, 'minute': u'26'} with default timezone <iso8601.iso8601.Utc object at 0x7f9bea76fd50> parse_date /root/.virtualenvs/caso/lib/python2.7/site-packages/iso8601/iso8601.py:184
2015-02-02 16:26:55.655 23343 DEBUG iso8601.iso8601 [-] Got u'2015' for 'year' with default None to_int /root/.virtualenvs/caso/lib/python2.7/site-packages/iso8601/iso8601.py:140
2015-02-02 16:26:55.655 23343 DEBUG iso8601.iso8601 [-] Got u'02' for 'monthdash' with default 1 to_int /root/.virtualenvs/caso/lib/python2.7/site-packages/iso8601/iso8601.py:140
2015-02-02 16:26:55.655 23343 DEBUG iso8601.iso8601 [-] Got 2 for 'month' with default 2 to_int /root/.virtualenvs/caso/lib/python2.7/site-packages/iso8601/iso8601.py:140
2015-02-02 16:26:55.655 23343 DEBUG iso8601.iso8601 [-] Got u'03' for 'daydash' with default 1 to_int /root/.virtualenvs/caso/lib/python2.7/site-packages/iso8601/iso8601.py:140
2015-02-02 16:26:55.655 23343 DEBUG iso8601.iso8601 [-] Got 3 for 'day' with default 3 to_int /root/.virtualenvs/caso/lib/python2.7/site-packages/iso8601/iso8601.py:140
2015-02-02 16:26:55.655 23343 DEBUG iso8601.iso8601 [-] Got u'15' for 'hour' with default None to_int /root/.virtualenvs/caso/lib/python2.7/site-packages/iso8601/iso8601.py:140
2015-02-02 16:26:55.656 23343 DEBUG iso8601.iso8601 [-] Got u'26' for 'minute' with default None to_int /root/.virtualenvs/caso/lib/python2.7/site-packages/iso8601/iso8601.py:140
2015-02-02 16:26:55.656 23343 DEBUG iso8601.iso8601 [-] Got u'55' for 'second' with default None to_int /root/.virtualenvs/caso/lib/python2.7/site-packages/iso8601/iso8601.py:140
2015-02-02 16:26:55.656 23343 DEBUG keystoneclient.session [-] REQ: curl -g -i -X GET https://egi-cloud.pd.infn.it:35357/v2.0/tenants/9d81ceb3caa547a7a593d98b667386cf/users -H "User-Agent: python-keystoneclient" -H "Accept: application/json" -H "X-Auth-Token: {SHA1}5da7361dc8ca7705fed72fa04ac925f96b21aea5" _http_log_request /root/.virtualenvs/caso/lib/python2.7/site-packages/keystoneclient/session.py:171
2015-02-02 16:26:55.753 23343 DEBUG keystoneclient.session [-] RESP: [200] content-length: 847 content-encoding: gzip vary: X-Auth-Token,Accept-Encoding server: Apache/2.2.15 (Scientific Linux) connection: close date: Mon, 02 Feb 2015 15:26:55 GMT content-type: application/json
RESP BODY: {"users": [{"enabled": true, "name": "/O=dutchgrid/O=users/O=egi/CN=Salvatore Pinto", "id": "010dd541467d4e21be31c2d63022c521"}, {"enabled": true, "name": "/C=IT/O=INFN/OU=Personal Certificate/L=Padova/CN=Marco Verlato", "id": "079b0a6b09234e9c870662b1659cf89a"}, {"enabled": true, "name": "/C=IT/O=INFN/OU=Personal Certificate/L=ENGINEERING RDLAB/CN=Pietro Fragnito", "id": "0e91a2fcd48044489170c6022cfd440a"}, {"enabled": true, "name": "/DC=es/DC=irisgrid/O=ciemat/CN=antonio-rubio", "id": "142f08da0d914631a2969db27a3256c5"}, {"enabled": true, "name": "/DC=es/DC=irisgrid/O=ifca/CN=Enol-Fernandez-delCastillo", "id": "25a5faedc4fa4ca8ae62a13fffe21a43"}, {"name": "admin", "id": "3df7f52f0a9f4900805d9ce52e579581", "enabled": true, "email": "test@test.com", "tenantId": "5e3e0f3a8d01411391ac61d7d30c0222"}, {"enabled": true, "name": "/DC=org/DC=terena/DC=tcs/C=CZ/O=CESNET/CN=Zdenek Sustr 4040", "id": "4e72065f05944298ac60e49741c10597"}, {"enabled": true, "name": "/C=UK/O=eScience/OU=Oxford/L=OeSC/CN=kashif mohammad", "id": "5270dd8cfacd47f492c898607a31658d"}, {"enabled": true, "name": "/C=IT/O=INFN/OU=Personal Certificate/L=Catania/CN=Diego Scardaci", "id": "5e7a33a1d4a74b00b39f3d367dc99f69"}, {"enabled": true, "name": "/C=UK/O=eScience/OU=Manchester/L=HEP/CN=andrew mcnab", "id": "aa175cf9b93443f9a48e675e7ec628f9"}, {"enabled": true, "name": "/C=DE/O=GridGermany/OU=Forschungszentrum Juelich GmbH/CN=Bjoern Hagemeier", "id": "b594ef13af854d738d0bb883e52fff93"}, {"enabled": true, "name": "/DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=lvillazo/CN=757145/CN=Luis Villazon Esteban", "id": "bf0aea2b6459417893c21b501a6c14e2"}, {"name": "accounting", "enabled": true, "email": null, "id": "d4952e17b9bd445297efc0972f790b40"}]}
_http_log_response /root/.virtualenvs/caso/lib/python2.7/site-packages/keystoneclient/session.py:199
2015-02-02 16:29:04.442 23343 CRITICAL caso [-] Unauthorized: Unauthorized (HTTP 401)
2015-02-02 16:29:04.442 23343 TRACE caso Traceback (most recent call last):
2015-02-02 16:29:04.442 23343 TRACE caso File "/root/.virtualenvs/caso/bin/caso-extract", line 10, in
marcoverl
commented
9 years ago ok it was due to the Nova API bug you pointed out in the documentation, when using with --extract_from 2015-02-04 option it worked fine (as root, as apel user still having auth errors)
marcoverl
commented
9 years ago but unfortunately the error still arise if --extract_from option is not used, even if the file /var/spool/caso/lastrun now does exist
marcoverl
commented
9 years ago ok, actually the behaviour above is not reproducible, i can have:
(caso)[root@egi-cloud ~]# caso-extract -v 2015-02-05 23:34:47.657 10262 INFO caso.extract.manager [-] Extracted 0 records for tenant 'EGI_FCTF' from 2015-02-05 22:28:09.735728+00:00 to now 2015-02-05 23:34:48.662 10262 INFO caso.extract.manager [-] Extracted 0 records for tenant 'WeNMR' from 2015-02-05 22:28:09.735728+00:00 to now 2015-02-05 23:34:51.124 10262 INFO caso.extract.manager [-] Extracted 4 records for tenant 'EGI_atlas' from 2015-02-05 22:28:09.735728+00:00 to now 2015-02-05 23:34:52.646 10262 INFO caso.extract.manager [-] Extracted 0 records for tenant 'EGI_ops' from 2015-02-05 22:28:09.735728+00:00 to now 2015-02-05 23:34:53.606 10262 INFO caso.extract.manager [-] Extracted 0 records for tenant 'EGI_dteam' from 2015-02-05 22:28:09.735728+00:00 to now 2015-02-05 23:34:56.131 10262 CRITICAL caso [-] ConnectionError: ('Connection aborted.', BadStatusLine("''",))
and a two minutes later everyhting ok:
(caso)[root@egi-cloud ~]# caso-extract -v 2015-02-05 23:36:11.152 10742 INFO caso.extract.manager [-] Extracted 0 records for tenant 'EGI_FCTF' from 2015-02-05 22:28:09.735728+00:00 to now 2015-02-05 23:36:12.508 10742 INFO caso.extract.manager [-] Extracted 0 records for tenant 'WeNMR' from 2015-02-05 22:28:09.735728+00:00 to now 2015-02-05 23:36:15.160 10742 INFO caso.extract.manager [-] Extracted 4 records for tenant 'EGI_atlas' from 2015-02-05 22:28:09.735728+00:00 to now 2015-02-05 23:36:17.844 10742 INFO caso.extract.manager [-] Extracted 0 records for tenant 'EGI_ops' from 2015-02-05 22:28:09.735728+00:00 to now 2015-02-05 23:36:18.773 10742 INFO caso.extract.manager [-] Extracted 0 records for tenant 'EGI_dteam' from 2015-02-05 22:28:09.735728+00:00 to now 2015-02-05 23:36:19.864 10742 INFO caso.extract.manager [-] Extracted 0 records for tenant 'EGI_lhcb' from 2015-02-05 22:28:09.735728+00:00 to now
so, i think i can close the issue.
Hello, i am not sure what i should replace: i have a cron job with: [root@egi-cloud ~]# cat /var/lib/osssm/cron -# extract and buffer usage records 0 /2 * * \ apel /usr/bin/osssm.extract
-# send buffered usage records to APEL/SSM 15 /12 * * \ apel /usr/bin/osssm.push
-# send buffered usage records to GOC 30 /24 * * \ apel /usr/bin/ssmsend
where: /usr/bin/osssm.extract , .push and /etc/osssmrc come from: [root@egi-cloud ~]# rpm -qf /usr/bin/osssm.extract apel-ssm-openstack-1.19-1.noarch and [root@egi-cloud ~]# rpm -qf /usr/bin/ssmsend apel-ssm-2.1.1-0.el6.noarch
In /etc/osssmrc i have some config. values similar to the one i have now in /etc/caso/caso.conf.
So, can i simply remove apel-ssm-openstack-1.19-1.noarch and replace /usr/bin/osssm.extract in the cron job with caso-extract? what about /usr/bin/osssm.push? is something done inside caso-extract?