codebase, does this look as if it would be hard to
implement? If I wanted to implement it myself, should I be looked at
the 2.4 code? We're running 2.2 locally, but I understand that 2.4 is
on the horizon.
--
Lars Kellogg-Stedman
Senior Technologist
Harvard University SEAS
Academic and Re
e.
Thanks,
--
Lars Kellogg-Stedman
Senior Technologist
Harvard University SEAS
Academic and Research Computing (ARC)
___
Users mailing list
Users@lists.opennebula.org
http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
improvement over the existing mechanism?
Is there work going on that would make this unnecessary?
Cheers,
--
Lars Kellogg-Stedman
Senior Technologist
Harvard University SEAS
Academic and Research Computing (ARC)
___
Users mailing list
Users@lists.opennebula.org
http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
> I think the best solution would be to change the econe client
> implementation to use the sha1 password, therefore the EC2_SECRET_KEY
> can be used in the same way for the three clients. The priority is CLI
>> ENV > ONE_AUTH
Sounds good to me!
--
Lars Kellogg-Stedman
S
sense
for the econe-* tools prefer ONE_AUTH over the EC2 variables? This
way EC2_SECRET_KEY could be set for eucatools or Elastic Fox, while
the econe-* tools could pull their config from wherever ONE_AUTH
points.
--
Lars Kellogg-Stedman
Senior Technologist
Harvard University SEAS
Academ
> Would you mind to try specifying:
> SSL_SERVER=arc-vm-opennebula.int.seas.harvard.edu:80
> instead of
> SSL_SERVER=arc-vm-opennebula.int.seas.harvard.edu
Both euca-describe-images and econe-describe-images fail with this change.
--
Lars Kellogg-Stedman
Senior Technologist
Harvar
et the OpenNebula tools working. Any thoughts?
--
Lars Kellogg-Stedman
Senior Technologist
Harvard University SEAS
Academic and Research Computing (ARC)
___
Users mailing list
Users@lists.opennebula.org
http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
on and see if we can solve the authentication issue.
--
Lars Kellogg-Stedman
Senior Technologist
Harvard University SEAS
Academic and Research Computing (ARC)
___
Users mailing list
Users@lists.opennebula.org
http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
ng application.
In the sort of situation you describe, there's not really any way for
OpenNebula to "check the storage connectivity", because any commands
that attempt to access the storage will get stuck in exactly the same
way.
--
Lars Kellogg-Stedman
Senior Technologist
Ha
lients work.
Before I open bug reports on these, I wanted to check in here and see
if I'm missing anything obvious. If it matters, we're running 2.2 on
CentOS 5.
--
Lars Kellogg-Stedman
Senior Technologist
Harvard University SEAS
Academic and Research Computing (ARC)
__
unts (e.g., everyone in IT
authenticates as the "IT" user, and everyone in CS50 authenticates as
the "CS50" user) -- unless the forthcoming release addresses some of
these issues.
--
Lars Kellogg-Stedman
Senior Technologist
Harvard Univer
such that we could implement access control policies without
having to modify the core tools.
--
Lars Kellogg-Stedman
Senior Technologist
Harvard University SEAS
Academic and Research Computing (ARC)
___
Users mailing list
Users@lists.opennebula.org
http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
few Ruby gems, we've been able
to install everything out of the stock CentOS repository. This way
you can spend more time learning OpenNebula and less time futzing
about with compiling all the requirements.
--
Lars Kellogg-Stedman
Senior Technologist
Harvard University SE
.254, 10.10.10.253]
...or something like that.
--
Lars Kellogg-Stedman
Senior Technologist
Harvard University SEAS
Academic and Research Computing (ARC)
___
Users mailing list
Users@lists.opennebula.org
http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
here that such a limit is defined.
/etc/one/auth/auth.conf looks like this:
:database: sqlite://auth.db
:authentication: simple
:quota:
:enabled: false
:defaults:
:cpu: 10.0
:memory: 1048576
:num_vms:
And I've never used the "oneauth quota ..." command.
--
Lars Kell
.19.254, MAC=5E:A5:0A:F3:13:FE]
In this case, we're using the "MAC prefix" model, so we're able to
pre-generate this list. This has solved the problem of OpenNebula
handing out the router address to virtual machines, at the cost of a
small amount of complexity.
--
Lars
,
that means we'd be pulling group information out of LDAP.
Cheers,
--
Lars Kellogg-Stedman
Senior Technologist
Harvard University SEAS
Academic and Research Computing (ARC)
___
Users mailing list
Users@lists.opennebula.org
http://lists.opennebu
FIXED
networks?
--
Lars Kellogg-Stedman
Senior Technologist
Harvard University SEAS
Academic and Research Computing (ARC)
___
Users mailing list
Users@lists.opennebula.org
http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
> reserved by the network operations group. Is my only solution to
> manually create leases using the "onevnet addlease" command?
Well, shoot. I can't manually add leases to a RANGED network, so this
solution is out, too.
--
Lars Kellogg-Stedman
Senior Technologist
Ha
te, regardless of the size
of the network.
Thanks,
--
Lars Kellogg-Stedman
Senior Technologist
Harvard University SEAS
Academic and Research Computing (ARC)
___
Users mailing list
Users@lists.opennebula.org
http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
e:a5:0a:f3:13:01, USED=1, VID=13 ]
How do I fix this? Do I simply not understand how ranged networks
work? Thanks for your help,
--
Lars Kellogg-Stedman
Senior Technologist
Harvard University SEAS
Academic and Research Computing (ARC)
___
Users mailing
21 matches
Mail list logo