The bug affects Kamic, which is LTS.
I think it would be a good idea to fix this for karmic too, wouldn't it ?
Karmic has still the 2.3.4.7 version.
--
nmbd doesn't start because of missing testparm
https://bugs.launchpad.net/bugs/572410
You received this bug notification because you are a member
Public bug reported:
Binary package hint: likewise-open-gui
The package likewise-open-gui add a menu shortcut in Applications >
Internet; this seems fairly wrong to me. I believe a better place would
be System > Administration.
Moreover, the menu icon could be changed from the Samba logo to
som
Public bug reported:
Binary package hint: likewise-open-gui
When clicking the Close Window button (the X button on the top right
corner) or pressing Alt-F4 in the Likewise Open GUI in hardy, all text
field get reset to blank but the window do not close.
likewise-open-gui 4.0.5-0ubuntu1 on Ubuntu
The problem, I believe, come from the fact that open-iscsi is brought up
(S25 in /etc/rcS.d) before networking (S40 in /etc/rcS.d).
It is my understanding that udev bring interfaces up as they are
discovered, which mean that "bare" interfaces (eth0, eth1, etc) happen
to be brought up before /etc/r
Public bug reported:
Binary package hint: likewise-open
The "Domain Join Authentication" dialog (what you got when you click the
Join Domain button) misspell "privileges".
** Affects: likewise-open (Ubuntu)
Importance: Undecided
Status: New
--
Typo in Likewise Open GUI (misspelle
This is fixed in latest upstream (likewise-4.1.0-1.24061-domainjoin).
--
Typo in Likewise Open GUI (misspelled "privileges")
https://bugs.launchpad.net/bugs/253394
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to likewise-open in ubuntu.
-
I do not think this bug is even remotely worthy of an SRU, but if an
update is ever done to the likewise-open-gui package in hardy, it would
be good to have it corrected. It's really an eyesore ... :(
--
Typo in Likewise Open GUI (misspelled "privileges")
https://bugs.launchpad.net/bugs/253394
Y
I still get the (rather unhelpful) error:
mount error 38 = Function not implemented
I am not sure if the problem is with mount.cifs, or if it is something about
the way I am set up. If someone who report success with backported 3.2.0 could
try with the 3.0.28a package in Steve's PPA, that
I am running 2.6.24-20.38 from hardy-proposed. /boot/config-`uname -r`
show that CONFIG_CIFS_UPCALL=y is set. If it work for you, that mean
the problem is somewhere else on my side.
--
cifs does not support kerberos authentication
https://bugs.launchpad.net/bugs/236830
You received this bug not
To follow-up regarding the comment from Steve on 2008-08-15, it does
work now indeed. Basically, it is entirely my fault for not configuring
the Samba server for Kerberos authentication. For the record, you need
to set the "use kerberos keytab" and "realm" options of smb.conf. Duh.
Steve: I see
Public bug reported:
Binary package hint: smbfs
When creating files on a CIFS-mounted filesystem, default ACL are not
inherited. However, directory created on same CIFS-mounted filesystem
works just fine.
Both server and client are Ubuntu 8.04. On the server, running samba
3.0.28a-1ubuntu4.5,
** Description changed:
Binary package hint: smbfs
When creating files on a CIFS-mounted filesystem, default ACL are not
inherited. However, directory created on same CIFS-mounted filesystem
works just fine.
Both server and client are Ubuntu 8.04. On the server, running samba
3
** Description changed:
Binary package hint: smbfs
When creating files on a CIFS-mounted filesystem, default ACL are not
inherited. However, directory created on same CIFS-mounted filesystem
works just fine.
Both server and client are Ubuntu 8.04. On the server, running samba
3
The problem could be on the server side. I just tested with Ubuntu
7.10, with the old smbmount and smb kernel module, and the behavior is
the same as when using mount.cifs and the cifs kernel module: directory
inherit ACL fine, but not files.
--
Default ACL not applied on files created through C
Just tested on Intrepid (both client and server), and I get the same
behavior: directory created through the CIFS mounted file system inherit
the default ACL correctly but files do not, while it work as expected
when creating either directory or file using smbclient.
--
Default ACL not applied on
Just tried using the latest upstream source (3.3.0pre2) on the server
side with Intrepid, and it fail too. I will report to Samba Bugzilla,
and see what they have to say.
--
Default ACL not applied on files created through CIFS filesystem (mount.cifs)
https://bugs.launchpad.net/bugs/271922
You r
However, on Intrepid when using the upstream 3.3.0pre2 from source, file
do not inherit default ACL for "other" even when the file is created
using smbclient.
I should also note that using an ACL for a named group instead of
"other" (ie, setfacl -m d:g:users:rwx) work as expected in all test
cases
The above solution is not entirely right, as the open-iscsi init script
will be run after /etc/rcS.d/mountall.sh, which mean that filesystem in
/etc/fstab that reside on iSCSI will not be available when mountall.sh
is ran.
--
boot order wrong for iscsi
https://bugs.launchpad.net/bugs/227848
You r
Debian have fixed two related bugs:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=423851
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=438542
The solution might be to sync from Debian. Package 2.0.869~rc4-1 is supposed
to include modification to the init script that would fix this proble
I have documentation to write with screenshot from likewise-open-gui,
and this typo just cannot get into it. I have a package for hardy that
fix it in my PPA:
deb http://ppa.launchpad.net/etienne-goyer-outlands/ubuntu hardy main
Attached a debdiff that correct the problem.
** Attachment
Dustin and myself worked on the bug today. We where able to fix the bug
with the following changes:
1. Add the _netdev option to filesystem on iscsi target in /etc/fstab.
We cannot do that retroactively for people who already have entries for
file system on iscsi target in fstab, so this will nee
I forgot to mention that the bit of code to add to open-iscsi init
script is from the Debian open-iscsi 2.0.869 package in unstable. So,
we will get it for jaunty in the next sync anyway.
--
boot order wrong for iscsi
https://bugs.launchpad.net/bugs/227848
You received this bug notification beca
> create cifs.upcall * * /usr/sbin/cifs.upcall %k %d
The line in /etc/request-key.conf should look like the following instead:
create cifs.spnego**/usr/sbin/cifs.upcall %k %d
The key name is indeed cifs.spnego, only the executable name change.
--
cifs does not support ker
slithy, kunzol above is wrong: nss-ldapd is indeed available in 8.04,
but it is not default and does not supersede libnss-ldap. It is a
completely different package than libnss-ldap (although it fill the same
use-case). I understand this bug concern libnss-ldap, not libnss-
ldap*d*.
--
LDAP and
Can we nominate that one for 8.04.2? Launchpad does not let me do it.
--
iSCSI install fails under hardy
https://bugs.launchpad.net/bugs/236640
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to open-iscsi in ubuntu.
--
Ubuntu-server-bugs
If there is an SRU for hardy, would it be possible to correct this bug
too? While annoying, I do not think this bug really justify an SRU by
itself, but it might be worth fixing if the opportunity arise, as the
current behavior of domainjoin without the --with-dnsupdate is somewhat
unintuitive.
-
It is documented in Likewise Open Installation and Administration Guide.
Short of removing ntpdate entirely (which you cannot do easily, as it is
part of ubuntu-minimal), I am not sure how you would prevent ntpdate
from being run when an interface come up.
--
ntpdate suggestion
https://bugs.launc
I have reported bug #322518 about disabling ntpdate being non-obvious.
But I guess warning about and/or having an option for changing the
default NTP server used in domainjoin-cli and -gui would be best.
--
ntpdate suggestion
https://bugs.launchpad.net/bugs/192597
You received this bug notificati
I can confirm the default ACL for other are being applied correctly on
file creation through a CIFS mount with the POSIX extensions disabled,
on hardy.
The ability to create pipe and socket is not important in my case, and I
think I can do without POSIX file locking. As such, disabling the POSIX
** Tags added: ipv6
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to eucalyptus in Ubuntu.
https://bugs.launchpad.net/bugs/628145
Title:
Eucalyptus does not understand IPv6
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists
** Changed in: netcfg (Ubuntu Lucid)
Milestone: None => ubuntu-10.04.3
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is a bug assignee.
https://bugs.launchpad.net/bugs/56679
Title:
provide a method to use a specified MAC-address as the installa
By design, the NSS library is expecting the database to be available and
fast to query. When the NSS database become unresponsive (as is the
case when using libnss-ldap and the the LDAP directory become
unavailable), this assumption breaks and functions such as getpwnam()
blocks, which can cause a
Unless I am mistaken, this bug render likewise-open DOA. Now that the
last update to openldap in maverick-proposed has gone through, I guess
it would be a good time to push this one.
Not trying to push anybody around. I swear, I would do it myself if I
had the credentials! :)
--
Existing patc
On 10-12-03 02:08 PM, Clint Byrum wrote:
> I also see in the
> DpkgTerminalLog.gz that nmbd fails to stop, meaning it is not running. I
> may be wrong here, but I believe nmbd is necessary for winbind.
No, nmbd is not strictly required for winbindd. But the fact that nmbd
fail to start is indeed
Dave: again, sorry I can't produce the correct text, as I am not sure
what the exact behavior is supposed to be. Feel free to mark as Won't
Fix, if you think it does not deserve to be clarified.
** Changed in: eucalyptus (Ubuntu)
Status: Expired => Confirmed
--
You received this bug noti
As a note, you need to turn on verbosity by adding -v to TFTP_OPTIONS in
/etc/default/tftpd-hpa, otherwise the daemon do not log file get.
Useful to know when testing.
Beside, I can confirm the proposed update fix the bug too.
--
You received this bug notification because you are a member of Ubu
As Thierry and Anders pointed out above, this might be causing breakage.
See bug #605326, for example.
Considering we are installing recommended package by default, this ought
to be reviewed. I think winbind should be made a Suggests of wine
instead, since the NTLM authentication feature is not s
Public bug reported:
Binary package hint: samba
The Samba postinst maintainer script systematically import all account
with uid >= 1000. This is so that user account and such have
corresponding Samba account. In most case, this is a good thing and
make. However, where the machine has been conf
The error seems to be cosmetic, as the service would still start (I have
not checked in depth, though). Still, the fix is trivial and really
ought to be SRU'ed at some point, IMHO.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to nagios
Public bug reported:
Binary package hint: bacula-console-qt
On lucid, in the Version Browser of bat, it is impossible to check the
latest version of a file. This is described in the following upstream
bug report: http://bugs.bacula.org/view.php?id=1550 (login using
anonymous/anonymous)
For co
I am not sure I understand the issue fully, so please bear with me if I
am missing something.
Since the ad idmap backend *is* read-only, isn't it to be expected that
you cannot change the "mapping" ? Was it even possible in an earlier
version of Samba?
I am also curious about what you are trying
There is no daily of the server flavour on http://cdimage.ubuntu.com,
but here is /var/log/syslog from Jaunty server ISO, when launched with
"iscsi=true".
Steve, contrary to what we discussed earlier today, I do think finally it is
the same error we get on jaunty and hardy after all. It does ap
Chris Puttick wrote:
> Consider me confused on the basis of my earlier comment showing how to
> configure Hardy so that iscsi volume mounts works consistently. It
> ain't broke, why fix it?
That is because you are not accessing the iSCSI target through a bonded
Ethernet interface. With plain Ethe
Quick test lead me to believe that open-iscsi 2.0.865-1ubuntu3.1 from
hardy-proposed work as explained by Steve. That is, the block device
appear after the bonded Ethernet is brought up. It is too late for the
file system on the iSCSI target to be mounted from /etc/fstab, but at
least we do not h
Attached is /var/log/syslog from the daily karmic server ISO (June
29th).
However, it does not include the fix Steve uploaded in comment 25 (open-
iscsi 2.0.865-1ubuntu4). As it is an installer bug, I guess it will ned
to find it's way into the daily build before I can test.
** Attachment added:
As I explained a couple months earlier (see comment 2), even if the path
to iscsi-iname is fixed, it still fail in the end. The installer goes
on just fine, but if you choose to configure a file system residing on
an iSCSI target to be mounted at boot time (not as the root file system,
just about
Thierry Carrez wrote:
> Not exactly, what I'm saying is that on *every* network that has a
> correct DNS setup, this change will result in a small performance hit
> and/or useless network noise. This is not a question of "large company
> networking". Everyone can setup dnsmasq for local name resolu
Steve, I built open-iscsi with the above debdiff, and iscsi_discovery
does work just like the unpatched version. I found two other bugs with
it (the block device is not being made available right away, and it
cause a kernel oops in certain circumstance), but I will be reporting
these separately.
Is still still an issue an issue on hardy, which ship with open-iscsi
2.0.865? If not, then I guess we should close this bug as invalid or
wontfix.
--
Open solaris iscsi target causes panic in open-iscsi
https://bugs.launchpad.net/bugs/159682
You received this bug notification because you are a
The kernel oops have been reported as bug #395323.
The target block device not being made available right away is not a
bug, it is the expected behavior. Sorry for the noise.
--
iSCSI install fails under hardy
https://bugs.launchpad.net/bugs/236640
You received this bug notification because you
I do not have the problem Kevin reports above; iscsi=true works just
fine for me. I tested using the karmic server CD image dated
08-Jul-2009 10:32 from the same location he does.
I am pleased to report the iSCSI installer support works just fine now for me.
The iSCSI dialog come up fine, the
Colin, as the bug is in the installer part of the package, I would need
an ISO to test. Or can I test using the netboot installer?
--
iSCSI install fails under hardy
https://bugs.launchpad.net/bugs/236640
You received this bug notification because you are a member of Ubuntu
Server Team, which is
The latest daily hardy server CD ISO (20090709) works just fine indeed.
When provided with the iscsi=true boot option, it will prompt for the
iSCSI target to use, the iSCSI target will show up as a block device in
the partitionner dialog, and you can use it for non-root file systems
just fine. I u
That is what I would guessed too, and I think it would be a good
default behavior. I know some people have very strong opinion on this
issue. Should it be discussed at a Server team meeting, or even as a
session in the next UDS? That way, we could get opinion from all
stakeholders and formulate
Public bug reported:
When running the restart target of eucalyptus-nc 1.6~bzr645-0ubuntu1 in
karmic, the restart fail because it cannot find the avahi-publish
executable. The package should then depend on avahi-utils, and maybe
check for the presence of the avahi-publish executable in the init
sc
Public bug reported:
Sample output of euca_conf ran on a cluster controller:
--
ubu...@t61p:~$ sudo euca_conf --register-nodes 192.168.144.65
INFO: We expect all nodes to have eucalyptus insta
This bug have been fixed in karmic. It should be SRUed for jaunty, or
marked WONTFIX, as appropriate.
--
eucalyptus-nc service fail to start at boot, cannot connect to libvirtd
https://bugs.launchpad.net/bugs/364723
You received this bug notification because you are a member of Ubuntu
Server Tea
This could be fixed relatively easily by calling euca_conf in the
postinst script of either eucalyptus-common or -cc, such as:
euca_conf --dhcpd /usr/sbin/dhcpd3
euca_conf --dhcp_user dhcpd
--
In /etc/eucalyptus/eucalyptus.conf, VNET_DHCPDAEMON and VNET_DHCPUSER should be
set to value a
Still a problem in Karmic.
--
eucalyptus-nc should depend on ssh
https://bugs.launchpad.net/bugs/411656
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to eucalyptus in ubuntu.
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubu
I have not yet verified that this is still a bug in karmic, but it
should be fixed if it is.
--
Any network mode beside SYSTEM fail because /var/run/eucalyptus/net do not exist
https://bugs.launchpad.net/bugs/365349
You received this bug notification because you are a member of Ubuntu
Server Team
I already reported that issue as bug #424541.
--
UEC installer does not set up a bridge device by default for Eucalyptus nodes
(NCs)
https://bugs.launchpad.net/bugs/425915
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to eucalyptus in ubun
Public bug reported:
Binary package hint: eucalyptus-nc
This is a wishlist item.
As it can be hard to track problems running instances on a node
controller caused by the node controller not supporting HVM, it would be
good if the package installer would warn of the situation. For example,
we co
I see the same symptoms here. eucalyptus-cc has been running for a bit
over a month now. That is also on jaunty amd64, eucalyptus-cc
1.5~bzr266-0ubuntu2.
cloudmas...@eucalyptus-frontend:~$ ps up 2642
USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND
110 2642 2.7 20.
I confirm I had exactly the same problem happen to me last week.
When looking at /var/log/eucalyptus/cloud-error.log, there was some
verbiage about a corrupted index or somesuch. Do you see something
similar?
Also, is it possible that you started the eucalyptus-cloud service from
within an SSH s
/vmlinuz-2.6.28-11-generic.manifest.xml
Are you sure you want to specify a different EC2 public certificate? [y/n]
y
Using specified EC2 public certificate: /home/etienne/.euca-lab/cloud-cert.pem.
Server.NotReady(406): The service is not ready to accept your request
Bundle upload failed.
On the
Public bug reported:
On karmic using Eucalyptus 1.6~bzr672-0ubuntu3, when trying to
deregister a Walrus server on the command-line, euca_conf reports that
the Walrus server is successfully deregistered, but some verbiage on the
command appears to indicate it was not. See below:
cloudmas...@uec-
Public bug reported:
On karmic with Eucalyptus 1.6~bzr672-0ubuntu3, if you download the
certificate bundle before you register a Walrus server, the eucarc file
in the bundle declare the following variable:
export S3_URL=http://BukkitInternal:8773/services/Walrus/
BukkitInternal is not an actual
Ok, I did the registration already, and it appears to have succeeded. I
guess this bug should be closed as Invalid for now, i will try to figure
out what happened with the registration.
--
Cannot upload bundle to Walrus
https://bugs.launchpad.net/bugs/429590
You received this bug notification be
Quick workaround on the frontend:
sudo cp ~eucalyptus/.ssh/id_rsa.pub ~eucalyptus/.ssh/authorized_keys
--
after UEC front-end (cluster) install, key sync stage of registration cannot
proceed without entering a password
https://bugs.launchpad.net/bugs/429087
You received this bug notification b
Public bug reported:
On a brand new installation of Eucalyptus 1.6~bzr672-0ubuntu3 on karmic,
after manually copying ~eucalyptus/.ssh/id_rsa.pub to
~eucalyptus/.ssh/authorized_keys and successfully registering the
cluster, registration of the walrus component fail with the following
error:
cloud
The in question is already there, and writable only by root, hence why
scp fail:
cloudmas...@uec-frontend:~$ sudo ls -l /var/lib/eucalyptus/keys//euca.p12
-rw-r--r-- 1 root root 21546 2009-09-14 18:06 /var/lib/eucalyptus/keys//euca.p12
--
Registering Walrus fail
https://bugs.launchpad.net/bugs/4
The following workaround allows you to proceed with walrus registration:
sudo chown eucalyptus:eucalyptus /var/lib/eucalyptus/keys/euca.p12
--
Registering Walrus fail
https://bugs.launchpad.net/bugs/429719
You received this bug notification because you are a member of Ubuntu
Server Team, whi
Public bug reported:
On karmic using Eucalyptus 1.6~bzr672-0ubuntu3, when you use "euca_conf
--get-credentials cred.zip" to retrieve the certificate bundle on the
frontend, the eucarc file contains the following declaration:
export S3_URL=http://127.0.0.1:8773/services/Walrus
export EC2_URL=http:
Public bug reported:
On karmic running Eucalyptus 1.6~bzr672-0ubuntu3, after installing a
node controller and registeringit successfully, it is impossible to run
an instance. On the frontend:
euca-describe-availability-zones verbose
AVAILABILITYZONEwarthogs10.153.108.210
AVAILABI
Public bug reported:
On karmic running Eucalyptus 1.6~bzr672-0ubuntu3, instances fail to
start. I have not been able to track down the cause. I systematically
get the following:
cloudmas...@uec-frontend:~$ euca-run-instances -t c1.medium -k warthogs-key
emi-073A1120
RESERVATION r-5254095A
** Attachment added: "nc.log"
http://launchpadlibrarian.net/31806315/nc.log
--
Instance fail to run
https://bugs.launchpad.net/bugs/429754
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to eucalyptus in ubuntu.
--
Ubuntu-server-bugs ma
*** This bug is a duplicate of bug 423465 ***
https://bugs.launchpad.net/bugs/423465
** This bug has been marked a duplicate of bug 423465
euca.p12 owned by root
--
Registering Walrus fail
https://bugs.launchpad.net/bugs/429719
You received this bug notification because you are a member o
I had the same problem when testing earlier today. I *believe*
(although I am not sure) that happen when you have not registered the
clc on the walrus machine. Are you running walrus on a different
machine than the cloud controller?
--
Eucalyptus hangs & euca-upload-bundle doesn't return
https:
The problem is indeed with eucalyptus. There is now a check in the init
script that will make it fail if the EUCALYPTUS value of the
configuration file is "not_configured". The config that shipped in the
last version indeed was. Somehow, the config file did not got upgraded
to the new version, d
Got the same problem upgrading a Eucalyptus frontend (running -cloud,
-cc, -walrus and -sc). However, we cannot accept the package
maintainer's version, as it will overwrite the NODES value in the
configuration file, which would make the frontend consider there is no
node controller. People runni
Public bug reported:
On karmic, after upgrading Eucalyptus from 1.6~bzr672-0ubuntu4 to
1.6~bzr746-0ubuntu1, trying to run an instance fail with the following
error:
cloudmas...@uec-frontend:~$ euca-run-instances -t c1.medium -k warthogs-key
emi-073A1120
Warning: failed to parse error message fro
Trevor,
Can you have a look at bug #430093, and see if it is the same bug that
you get? If yes, could you add a comment with relevant details (such as
the above log snippet).
Thanks!
--
Eucalyptus cloud controller stops working suddenly
https://bugs.launchpad.net/bugs/428010
You received this
You will also want to make eth0 manual ("iface eth0 inet manual"),
otherwise both the bridge and eth0 will get an IP, making the routing
table funny.
--
eucalyptus node install results in broken /etc/network/interfaces
https://bugs.launchpad.net/bugs/430820
You received this bug notification beca
Colin, for me on jaunty, the following /etc/network/interfaces result in
a system with broken network (ie, cannot ping or connect to anything):
---
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
ifa
Unfortunately, I had to revert back to 1.5 for a specific project, and I
do not have the hardware to run two clusters in parallel (a stable one
on jaunty/1.5, and one for testing on karmic/1.6). I will not be able
to test any earlier than late next week. Sorry! :(
--
Instance fail to run
https
Do not forget to create /var/run/eucalyptus/net/ too (per bug #365349),
otherwise only SYSTEM mode will work.
--
/var/run/eucalyptus is not being set with correct permissions on machine reboot
https://bugs.launchpad.net/bugs/431114
You received this bug notification because you are a member of Ub
Not Dan, but here's my take anyway.
I would say it is fairly critical. The EBS functionality (on which the
block device attach/detach functionality depends) is a pretty important
feature. Without, data persistence is not obvious. For example, you
would run MySQL in the cloud by keeping table da
Dustin Kirkland wrote:
> Note that I had to modprobe acpiphp. Perhaps we should consider loading
> this module in init or in modules.conf.
I have reported this issue in bug #364916.
--
dynamic block device attach/detach not functional with karmic KVM
https://bugs.launchpad.net/bugs/432154
You r
On 2008-08-06, Steve had this tidbit of wisdom:
> If you are only using libnss-ldap without nscd, there is nowhere in the
> model for this reachability information to be stored. If you use nscd,
> results will be cached in the event the server is down.
Well, yes and no. Enumeration of NSS databas
Joseph Salisbury wrote:
> Hmm. I wonder if this could be related to the bios. I'll check it to
> ensure the correct settings are enabled for KVM. Could an error like
> this occur if the bios was not setup correctly?
Yes, indeed.
--
Unable to start EUC instances - no supported architecture for
Public bug reported:
The copyright file of eucalyptus in karmic is incorrect. It states that
Eucalyptus is under a BSD-derived license, when it is really is under
GPLv3 at this point. Please see http://www.eucalyptus.com/licenses/,
and check the header of various source files for confirmation.
Neil Levine wrote:
> In fact, it should say "Ubuntu Enterprise Cloud, powered by Eucalyptus(TM)".
T,FTFY
--
Etienne Goyer
Technical Account Manager - Canonical Ltd
Ubuntu Certified Instructor
~= Ubuntu: Linux for Human Beings =~
--
UEC management interface still has Eucaly
uld get somewhere on Eucalyptus, that would be great.
--
Etienne Goyer
Technical Account Manager - Canonical Ltd
Ubuntu Certified Instructor
~= Ubuntu: Linux for Human Beings =~
--
Cloud Web interface should allow overcommit on CPU
https://bugs.launchpad.net/bugs/457864
You received this bug notifica
Public bug reported:
The euca_conf script, shipped in eucalyptus-common, is missing command-
line completion. This would be nice to have at some point.
** Affects: eucalyptus (Ubuntu)
Importance: Wishlist
Status: New
** Changed in: eucalyptus (Ubuntu)
Importance: Undecided => W
Public bug reported:
The configuration file /etc/eucalyptus/eucalyptus.conf, used by all
Eucalyptus services (-cloud, -cc, -nc, etc) is very confusing and
practically undocumented. The inline comments are helpful, but they do
not provide enough context for the administrator to decide which
config
Public bug reported:
In karmic eucalyptus 1.6~bzr931-0ubuntu7, the output of "euca_conf
--help" is wrong about the argument to remove a node from the cluster.
It states the argument is --delete-nodes, while it should really be
--deregister-nodes.
** Affects: eucalyptus (Ubuntu)
Importance: L
Public bug reported:
In karmic, eucalyptus 1.6~bzr931-0ubuntu7, the text of the
eucalyptus/publicips debconf template is wrong. It says the following:
Please specify one or more ranges of IP addresses, e.g.:
192.168.1.100-192.168.1.199
or
192.168.2.50-192.168.2.99 192.168.2.150-192.168.2.199
Sorry guys, this was a user error. I was using a range in
VNET_PUBLICIPS that was not in use on the machine. Sorry for the noise!
** Changed in: eucalyptus (Ubuntu)
Status: New => Invalid
--
The text debconf template eucalyptus/publicips is wrong
https://bugs.launchpad.net/bugs/459204
Y
Sounds good now. I have no idea where the magic operate, as
/etc/network/if-up.d/ntpdate do not check the desktop environment
setting, but manually-set time persist across reboot now. Thanks, I
guess this can be closed.
--
Time is being adjusted by ntpdate even if you choose to manage time manu
Dustin, thanks a lot for that fix! This will save tons of grieves to
lots of people down the road. I know *I* lost a couple of hours before
figuring out that VT extensions where disabled in the BIOS ... :D
--
kvm disabled in bios (was: Unable to start EUC instances - no supported
architecture
1 - 100 of 139 matches
Mail list logo
