Jaromír Talíř wrote:
Mark J Elkins píše v Út 03. 03. 2009 v 18:38 +0200:
fred-manager is script that can be used to install fred under local (non
system) user in one of his directories. This has a lot of advantages.
You can run many Fred installations concurrently, you can easily
uninstall it by just deleting and so on. We use this for unit tests, for
performance tests etc.
So for a production server - what does one do? - copy everything to
"/" ???
As suggested on
http://fred.nic.cz/wiki/download:
For c/c++ components use configure, make, make install(root access)
commands.
For python components do as root 'python setup.py install'
On our production servers, we use ubuntu package repository on
archive.nic.cz for installation. Fedora packages repository is also
there but Gentoo repository is just in our plans. Your help in setting
up such repository would be helpful.
Will do.
Its a bug in
Gentoo Package-management
..first I deleted omniORB
Then:-
# emerge omniorbpy -v
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild N ] net-misc/omniORB-4.0.5 USE="ssl" 0 kB
[ebuild N ] dev-python/omniorbpy-2.5 USE="ssl" 0 kB
...
then.. (at the end of installing omniorbpy-2.5)
* Detected file collision(s):
*
* /usr/lib/python2.5/site-packages/omniidl_be/__init__.pyc
* /usr/lib/python2.5/site-packages/omniidl_be/__init__.py
* net-misc/omniORB-4.0.5
* /usr/lib/python2.5/site-packages/omniidl_be/__init__.py
* /usr/lib/python2.5/site-packages/omniidl_be/__init__.pyc
*
* Package 'dev-python/omniorbpy-2.5' NOT merged due to file collisions.
ie - both packages are trying to own the same file - and Gentoo does not
like that.
Contents of one of the files is:
#
# Empty file to convince Python that this is a module.
#
netwisdom seems to be to delete the file - then (re)install omniorbpy-2.5.
The bug was fixed - but is back again - so this needs to be noted to
watch out for in Gentoo installs.
After this - I recompiled from scratch.
Results are towards the end of the email.
My Gentoo colleagues use more recent versions of omniORB (omniORB-4.1.3
and omniORBpy-3.3) which are available by adding 'net-misc/omniORB ~x86'
and 'dev-python/omniorbpy ~x86' to /etc/portage/package.keywords. They
didn't have any problems with those packages. I don't expect any
problems with version 4.0 but, using actual version is better.
I just love using ~x86 for my own personal stuff - but it does give
problems at times - being the 'unstable' branch.
I too prefer to use the Stable version of things for live servers.
Regarding
'cron' - on Gentoo - mortal users can not cd into /var/spool/cron
$ ls -l /var/spool/
total 16
drwxr-x--- 4 root cron 4096 May 26 2008 cron
drwx--x--- 3 root lp 4096 Mar 2 17:47 cups
drwxr-x--- 6 mail mail 4096 Feb 2 20:05 exim
lrwxrwxrwx 1 root root 10 Feb 2 18:38 mail -> /home/mail
drwxrwxr-x 2 root mail 4096 May 26 2008 mail.dist
fred@fred ~ $ cd /var/spool/cron
-su: cd: /var/spool/cron: Permission denied
They can have a crontab though - if "/etc/cron.allow" has your name
and/or "/etc/cron.deny" does not (from the man page of crontab)
Thats using Paul Vixie's cron system.
OK, this is fred-manager false expectation that it's enabled by default.
We should do some check before adding job to user cron. If you enable it
you will get regular zone file generation.
I ended up "chmod 751 /var/spool/cron" as well as adding my user
"fred"
to /etc/cron.allow
I quote from
the 'howto'
FRED is designed to run Linux (and was tested on Linux only), but will
probably run on any Unix operating system which meets the requirements.
FRED requires following additional software to be installed:
* Apache <http://httpd.apache.org> Apache web server 2.x
* PostgreSQL <http://www.postgresql.org> database version 8.x
* OmniORB <http://omniorb.sourceforge.net/> CORBA server version 4.0
or better
* Boost <http://www.boost.org/> C++ libraries version 1.20 or better
* libdaemon <http://0pointer.de/lennart/projects/libdaemon/>
libdaemon library
Opps - 5 packages - not 4.
You do have a "
* ... " as well - but that could be anything!
Now I see. I apology ourselves for 'how to' page. It's slightly outdated
and not all requirements are listed there. And some of then (libdaemon)
are not needed at all. To handle dependencies you have three ways:
* We created diagram of dependencies on
http://fred.nic.cz/attachment/wiki/attachments/component_schema.png
* You can check .spec files and setup.cfg files inside tarball packages
to see dependency package names for rpm based system and try to find
similar in your distribution
* You can go through step by step installation as you did and checks
should inform you about missing dependency - but as you found out , for
example dependency for omniorbpy in fred-pyfred si missing.
Remaining part of installation 'how to' si about 90% still actual but
'fred-manager' script should automate this installation at all so maybe
it's worth to check this script and gain some information from it.
Ran install again and this time - ended with:-
All done!
cat: /home/fred/local_named.template: No such file or directory
Ooops, this is really missing component and I forgot it when uploading
fred-manager script on website. I will have to update fred-manager
script and embed it inside somehow. I attached this file to this email
to allow you finish this installation.
As a recapitulation for what we should do regarding your findings :
- update dependency control of fred-pyfred to check for omniorbpy
- update installation of cron job for local user to check if this is
possible at all
- incorporate named start up script to fred-manager to be resolve
dependency on external file.
Jaromir
When running ./fred-manager start
I now get...
SUCCESS: Starting PostgreSQL
SUCCESS: Starting omniNames...
SUCCESS: Starting FRED central registry CORBA servers...
SUCCESS: Starting Apache...
SUCCESS: Starting FRED webadmin HTTP server...
SUCCESS: Starting local named
Looking better.
In the "install" stage - I did get:-
----------------------------------------------------------------------------------------
running install_egg_info
Removing
/home/fred/root/lib/python2.5/site-packages/fred_pyfred-2.1.2-py2.5.egg-info
Writing
/home/fred/root/lib/python2.5/site-packages/fred_pyfred-2.1.2-py2.5.egg-info
file /home/fred/download/src/fred-pyfred-2.1.2/pyfred/idlstubs.py (for
module pyfred.idlstubs) not found
file /home/fred/download/src/fred-pyfred-2.1.2/pyfred/idlstubs/ccReg.py
(for module pyfred.idlstubs.ccReg) not found
file
/home/fred/download/src/fred-pyfred-2.1.2/pyfred/idlstubs/ccReg__POA.py
(for module pyfred.idlstubs.ccReg__POA) not found
writing list of installed files to 'install.log'
normalize_record
All done!
----------------------------------------------------------------------------------------
Should I worry?
Tried a few things...
./root/bin/fred-client
FredClient 2.1.2
Type "help", "license" or "credits" for more information.
Using configuration from /home/fred/root/etc/fred/fred-client.conf
Connecting to localhost, port 22351 ...
ERROR: READ HEADER socket.sslerror: (6, 'TLS/SSL connection has been
closed')
Server didn't return Greeting message. Contact server administrator.
Web connected - and gave me:-
FRED
* Web administration interface <http://fred:22353>
* Web whois <http://fred:22354/whois/>
* List of registrars <http://fred:22354/whois/registrars.py>
* Public requests <http://fred:22354/whois/publicrequest.py>
To test unix whois call:
whois -h fred -p 22352 QUERY
To test EPP client call:
fred-client -h fred -p 22351 -u REG-FRED_A -w passwd
or download, unpack and run prepared client package
<http://fred:22354/fred-client_2.1.2.zip>
Zone is generated every minute. To test generated zone using DNS
protocol call:
dig AXFR cz @fred -p 22355
Or you can download generated zone using http protocol on following links:
* * <http://fred:22354/zones/db.*>
I don't think the list at the end looks correct.
Clicking on the links results in errors - eg
"whois" gives me:-
Internal ccregproxy errors:
Traceback (most recent call last):
File "/home/fred/root/lib/python2.5/site-packages/fred_whois/ccregproxy.py",
line 93, in __init__
self.__admin = self.getCorbaObject(rootContext, 'WebWhois', 'Admin')
File "/home/fred/root/lib/python2.5/site-packages/fred_whois/ccregproxy.py",
line 112, in getCorbaObject
obj = context.resolve(cosname)
File "//usr/lib/python2.5/site-packages/CosNaming_idl.py", line 215, in
resolve
return _omnipy.invoke(self, "resolve",
_0_CosNaming.NamingContext._d_resolve, args)
<class 'omniORB.CORBA.COMM_FAILURE'>: Minor: 0x41540006, COMPLETED_YES.
Whois...
Maybe something still is missing?
Thanks!
------------------------------------------------------------------------
_______________________________________________
Fred-users mailing list
Fred-users(a)lists.nic.cz
https://lists.nic.cz/mailman/listinfo/fred-users
--
. . ___. .__ Posix Systems - Sth Africa
/| /| / /__ mje(a)posix.co.za - Mark J Elkins, SCO ACE, Cisco CCIE
/ |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496