Oct 31, 2013
I'm not an astronomer, but since I was 10 I've had enough curiosity to let me look at night skies and practice the base notions of amateur astronomy. 2013 is a lucky year for comet observations, C/2011 L4 (PANSTARRS), C/2012 F6 (Lemmon) for example and currently transiting C/2012 S1 (ISON).
Not all sky bodies can be natively computed by PyEphem. A comet must be loaded from external catalog definitions of orbital parameters. PyEphem documentation provides links to various catalogs.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
gianluca:~$ mkvirtualenv astropy --no-site-packages New python executable in astropy/bin/python Installing setuptools............done. Installing pip...............done. gianluca:~$ workon astropy (astropy)gianluca:~$ pip install ephem Downloading/unpacking pyephem Downloading pyephem-18.104.22.168.tar.gz (703kB): 703kB downloaded Running setup.py egg_info for package pyephem Installing collected packages: pyephem Running setup.py install for pyephem building 'ephem._libastro' extension gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -Ilibastro-3.7.5 -I/usr/include/python2.7 -c extensions/_libastro.c -o build/temp.linux-x86_64-2.7/extensions/_libastro.o ... ... ... Successfully installed pyephem Cleaning up... (astropy)gianluca:~$
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
import ephem # load Comet ISON object from catalog http://www.minorplanetcenter.net/iau/Ephemerides/Comets/Soft03Cmt.txt ison = ephem.readdb("C/2012 S1 (ISON),h,11/28.7747/2013,62.3990,295.6529,345.5644,1.000002,0.012444,2000,7.5,3.2") date = '2013/10/31' # compute on date ison.compute(date) # define an observer Rome = ephem.city('Rome') rome_watcher = ephem.Observer() rome_watcher.lat = Rome.lat rome_watcher.lon = Rome.lon rome_watcher.date = date # print some useful data computed on the loaded body print("Tracking object: %s on date: %s from: %s" % (ison.name, date, Rome.name)) print "%s is in constellation: %s with magnitude %s" % (ison.name, ephem.constellation(ison), ison.mag) print("Rome next rising: %s" % rome_watcher.next_rising(ison)) print("Rome next setting: %s" % rome_watcher.next_setting(ison)) print("Earth distance: %s AUs" % ison.earth_distance) print("Sun distance: %s AUs" % ison.sun_distance)
1 2 3 4 5 6 7
(astropy)gianluca:~$ python tracking_comet_ison.py Tracking object: C/2012 S1 (ISON) on date: 2013/10/31 from: Rome C/2012 S1 (ISON) is in constellation: Leo with magnitude 8.07 Rome next rising: 2013/10/31 01:12:31 Rome next setting: 2013/10/31 14:07:39 Earth distance: 1.24149298668 AUs Sun distance: 1.00681865215 AUs
Clear skies to all :) and have fun!
Jan 30, 2013
Couldn't miss this, which I think is quite appropriate here ;) Enjoy this short Video published in today's APOD
Oct 02, 2009
Apache2 can use several authentication methods and options in order to allow access to the same resource, configured in a single VirtualHost.
In the following case i've illustrated how i solved the needing to access via
two different authentication/authorization methods the same
<Location></Location> by users registered on different authentication
systems and so to have different kinds of permissions on the resource, in this
case, subversion repositories.
The developers team of the company i actually work for, expressed the needing to give external occasional supporting developers, access to our subversion repositories made available through Apache2 HTTPS connection, behind a Nginx reverse proxy. They didn't want to register the external developers in our corporate SSO (OpenLDAP), instead they wanted to have them in separate authentication/authorization system, able to manage permissions on the repositories too.
Ubuntu 8.04 LTS in KVM virtual machine
Apache2 modules, basically the following:
authn_alias_module, which is in the core as demonstrated by:
root@vm:/etc/apache2/sites-available# dpkg -S mod_authn_alias.so
An OpeLDAP server somewhere, already giving authentication;
Subversion installed and functional on the same machine and already giving privileges management through a svn_auth_file.
This functionality is available by using the apache2 directive:
AuthnProviderAlias via the authn_alias_module obtained installing the
package apache2.2-common. The directive's operating context is: server config,
so it has to be inserted, in the case of Debian-based systems, in the
The purpose is to to configure a set of authentication methods that can be
made available to the VirtualHost's Location directives. The directive allows
to define the method itself, a name for a single method and other specific
configuration parameters, by specifing a directive for every single
authentication method to be used. The
AuthBasicProvider directive can then
be used in the Location directives to make effectively use of them listing
names after it. In this way the administrator can use a mix of authentication
methods as needed per VirtualHost's Locations. Other specific configuration
can be used inside the Location directive itself, as the LDAP DN, paths to
privileges files and so on.
For this case i've used
apache2-mpm-itk, which is stated to be still in
experimental stage, so use it at your own risk, surely there are other methods
to make an Apache2 VirtualHost run under a specified user. Furthermore there
has to be take into consideration that the mpm-itk is a de facto version of a
prefork, so: no threading.
The choice to make this VirtualHost running under a specified user is to give DAV physical access to the repositories in a permissions' coherent way, since the readings/writings operations are made by dav_svn_module installed via libapache2-svn Debian package.
The "AssignUserID uid gid" allows to specify, respectively, user name and group name to run under and its specific to mpm-itk
The usage of "UseCanonicalName on" makes DAV correctly identifying names to access the repositories since i'm using apache as a backend, in this way it correctly determines names as the Nginx reverse proxy passes through.
External users are authenticated on a htpasswd file, their permissions and privileges on the repositories are configured in a svn_auth_file, which defines users, groups of users and kind of permissions, it's related to only subversion, and in this case, is the second authentication/authorization system.
A configuration example follows:
1 2 3 4 5 6 7 8 9 10
<AuthnProviderAlias ldap ldap1 > AuthBasicProvider ldap # just an example AuthLDAPURL "ldap://IP_or_DOMAIN/ou=organization-unit,DC=domain,DC=tld?uid?sub?" </AuthnProviderAlias> <AuthnProviderAlias file svnfile> AuthUserFile /path/to/your/.htpasswd AuthzSVNAccessFile /path/to/your/svn_conf/authz_access.conf </AuthnProviderAlias&>
VirtualHost.conf excerpt(replace the file name accordingly):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36
<VirtualHost *> ServerName scm.domain.tld ServerAdmin firstname.lastname@example.org ErrorLog /var/logs/error CustomLog /var/logs/access combined # accept up to 10MB file size uploads LimitRequestBody 10485760 # assign the uid and gid user to this VH AssignUserID uid gid UseCanonicalName on <Location /repos> DAV svn SVNParentPath /path/to/svn_repos_dir SVNListParentPath on AuthBasicProvider ldap1 svnfile AuthType basic AuthName "Your REALM name here" AuthzLDAPAuthoritative on # owned by uid AuthzSVNAccessFile /path/to/conf/authz_access.conf require valid-user require ldap-group cn=gid,ou=group,dc=domain,dc=tld </Location> </VirtualHost>
In this way it'll be possibile access the repositories with a URL like https://domain.tld/repos/repo_name by using a registered user name in either OpenLDAP or htpasswd file when the authentication credentials will be requested. The users in the htpasswd file will be subject to the permissions defined in the SVN authentication file /path/to/conf/authz_access.conf.
The configuration illustrated here is just A solution not THE solution, i think there can be find other ways of accomplishing the same results, so use the above instructions at your own risk, i'm not responsible of what the reader does on her/his administered systems.
Moon at 34:47:35.2, 149:07:05.1 observing from Rome, IT
Powered by Moonwatcher.it ShortPosts.