[Bug 1379567] Re: maas-proxy is an open proxy with no ACLs; it should add networks automatically

2016-03-31 Thread Jeff Lane
** Tags added: hwcert-server

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1379567

Title:
  maas-proxy is an open proxy with no ACLs; it should add networks
  automatically

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1379567/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1379567] Re: maas-proxy is an open proxy with no ACLs; it should add networks automatically

2016-03-31 Thread Jeff Lane
This also needs a 1.9 target as well.  I just discovered this while
investigating proxy issues on a customer MAAS server and found that they
have an open maas proxy with a ton of external connections to it :/

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1379567

Title:
  maas-proxy is an open proxy with no ACLs; it should add networks
  automatically

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1379567/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1508565] Re: maas uses 3.13 (hwe-t) kernel which does not work on non-virtual IBM power

2016-03-15 Thread Jeff Lane
Unblocking cert on this since we can now deploy using HWE-V or later via
MAAS

** Tags removed: blocks-hwcert-server

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1508565

Title:
  maas uses 3.13 (hwe-t) kernel which does not work on non-virtual IBM
  power

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1508565/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1547311] [NEW] Installing MAAS in Trusty fails to restart apache2 (traceback about the maas user when restarting apache2)

2016-02-18 Thread Jeff Lane
Public bug reported:

Installed a VM with 14.04.3, did a full dist-upgrade and then installed
maas from the Trusty repos.

Since no newer maas has been SRUd yet, 1.7.6 is the only MAAS available
to trusty unless you know about the PPAs.  So normal users would end up
with 1.7.6, not 1.9 by default.

Installed maas and the restart of Apache failed.  Looking in the apache error 
logs and I see the following trace:
[Thu Feb 18 22:01:44.412117 2016] [:error] [pid 9747:tid 140636476237696] 
mod_wsgi (pid=9747): Target WSGI script '/usr/share/maas/wsgi.py' cannot be 
loaded as Python module.
[Thu Feb 18 22:01:44.412255 2016] [:error] [pid 9747:tid 140636476237696] 
mod_wsgi (pid=9747): Exception occurred processing WSGI script 
'/usr/share/maas/wsgi.py'.
[Thu Feb 18 22:01:44.412371 2016] [:error] [pid 9747:tid 140636476237696] 
Traceback (most recent call last):
[Thu Feb 18 22:01:44.412411 2016] [:error] [pid 9747:tid 140636476237696]   
File "/usr/share/maas/wsgi.py", line 39, in 
[Thu Feb 18 22:01:44.412567 2016] [:error] [pid 9747:tid 140636476237696] 
start_up()
[Thu Feb 18 22:01:44.412624 2016] [:error] [pid 9747:tid 140636476237696]   
File "/usr/lib/python2.7/dist-packages/maasserver/start_up.py", line 62, in 
start_up
[Thu Feb 18 22:01:44.412752 2016] [:error] [pid 9747:tid 140636476237696] 
security.get_shared_secret()
[Thu Feb 18 22:01:44.412771 2016] [:error] [pid 9747:tid 140636476237696]   
File "/usr/lib/python2.7/dist-packages/provisioningserver/utils/twisted.py", 
line 113, in wrapper
[Thu Feb 18 22:01:44.412961 2016] [:error] [pid 9747:tid 140636476237696] 
return func_in_reactor(*args, **kwargs).wait(timeout)
[Thu Feb 18 22:01:44.412986 2016] [:error] [pid 9747:tid 140636476237696]   
File "/usr/lib/python2.7/dist-packages/crochet/_eventloop.py", line 219, in wait
[Thu Feb 18 22:01:44.413210 2016] [:error] [pid 9747:tid 140636476237696] 
result.raiseException()
[Thu Feb 18 22:01:44.413253 2016] [:error] [pid 9747:tid 140636476237696]   
File "/usr/lib/python2.7/dist-packages/twisted/python/threadpool.py", line 191, 
in _worker
[Thu Feb 18 22:01:44.414141 2016] [:error] [pid 9747:tid 140636476237696] 
result = context.call(ctx, function, *args, **kwargs)
[Thu Feb 18 22:01:44.414166 2016] [:error] [pid 9747:tid 140636476237696]   
File "/usr/lib/python2.7/dist-packages/twisted/python/context.py", line 118, in 
callWithContext
[Thu Feb 18 22:01:44.414482 2016] [:error] [pid 9747:tid 140636476237696] 
return self.currentContext().callWithContext(ctx, func, *args, **kw)
[Thu Feb 18 22:01:44.414502 2016] [:error] [pid 9747:tid 140636476237696]   
File "/usr/lib/python2.7/dist-packages/twisted/python/context.py", line 81, in 
callWithContext
[Thu Feb 18 22:01:44.414528 2016] [:error] [pid 9747:tid 140636476237696] 
return func(*args,**kw)
[Thu Feb 18 22:01:44.414541 2016] [:error] [pid 9747:tid 140636476237696]   
File "/usr/lib/python2.7/dist-packages/provisioningserver/utils/twisted.py", 
line 148, in wrapper
[Thu Feb 18 22:01:44.414559 2016] [:error] [pid 9747:tid 140636476237696] 
return func(*args, **kwargs)
[Thu Feb 18 22:01:44.414571 2016] [:error] [pid 9747:tid 140636476237696]   
File "/usr/lib/python2.7/dist-packages/maasserver/utils/async.py", line 152, in 
call_within_transaction
[Thu Feb 18 22:01:44.414705 2016] [:error] [pid 9747:tid 140636476237696] 
with transaction.atomic():
[Thu Feb 18 22:01:44.414724 2016] [:error] [pid 9747:tid 140636476237696]   
File "/usr/lib/python2.7/dist-packages/django/db/transaction.py", line 237, in 
__enter__
[Thu Feb 18 22:01:44.415039 2016] [:error] [pid 9747:tid 140636476237696] 
if not connection.get_autocommit():
[Thu Feb 18 22:01:44.415058 2016] [:error] [pid 9747:tid 140636476237696]   
File "/usr/lib/python2.7/dist-packages/django/db/backends/__init__.py", line 
324, in get_autocommit
[Thu Feb 18 22:01:44.415670 2016] [:error] [pid 9747:tid 140636476237696] 
self.ensure_connection()
[Thu Feb 18 22:01:44.415690 2016] [:error] [pid 9747:tid 140636476237696]   
File "/usr/lib/python2.7/dist-packages/django/db/backends/__init__.py", line 
124, in ensure_connection
[Thu Feb 18 22:01:44.415713 2016] [:error] [pid 9747:tid 140636476237696] 
self.connect()
[Thu Feb 18 22:01:44.415725 2016] [:error] [pid 9747:tid 140636476237696]   
File "/usr/lib/python2.7/dist-packages/django/db/utils.py", line 99, in __exit__
[Thu Feb 18 22:01:44.416023 2016] [:error] [pid 9747:tid 140636476237696] 
six.reraise(dj_exc_type, dj_exc_value, traceback)
[Thu Feb 18 22:01:44.416042 2016] [:error] [pid 9747:tid 140636476237696]   
File "/usr/lib/python2.7/dist-packages/django/db/backends/__init__.py", line 
124, in ensure_connection
[Thu Feb 18 22:01:44.416065 2016] [:error] [pid 9747:tid 140636476237696] 
self.connect()
[Thu Feb 18 22:01:44.416113 2016] [:error] [pid 9747:tid 140636476237696]   
File "/usr/lib/python2.7/dist-packages/django/db/backends/__init__.py", line 
112, in connect
[Thu Feb 18 22:01:44.416137 2016] 

[Bug 1520979] Re: Grub multiboot is unable to load Xen under EFI

2016-01-20 Thread Jeff Lane
I have seen this issue as well, after being pointed to problems booting
Xen w/ Ubuntu by a colleague.

To recreate this I did the following:

Deployed a server in UEFI mode via MAAS 1.9 using the latest Xenial images from 
the MAAS daily image stream.
After deployment, SSH'd to the server and installed xen-hypervisor-4.6-amd64 
via apt-get.
Rebooted system after installation of Xen.

The system then attempted to EFI PXE (set to do so by default).  It
successfully PXEd and the MAAS server directed it to boot locally.  Then
it attempted to boot the Xen Hypervisor and halted at loading the
initial ramdisk.

At that point, the system abended and rebooted.  It was completely
unable to boot Xen.

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to xen in Ubuntu.
https://bugs.launchpad.net/bugs/1520979

Title:
  Grub multiboot is unable to load Xen under EFI

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xen/+bug/1520979/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1484268] Re: MAAS not auto-detecting/auto-entering credentials for HP Proliant ML310E G8 V2 server

2016-01-14 Thread Jeff Lane
Removing the blocker tag since this is no longer reproducible.

** Tags removed: blocks-hwcert-server

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1484268

Title:
  MAAS not auto-detecting/auto-entering credentials for HP Proliant
  ML310E G8 V2 server

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1484268/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1508565] Re: maas uses 3.13 (hwe-t) kernel which does not work on non-virtual IBM power

2016-01-14 Thread Jeff Lane
Will this be fixed in the 1.9 release?

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1508565

Title:
  maas uses 3.13 (hwe-t) kernel which does not work on non-virtual IBM
  power

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1508565/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


Re: [Bug 1514960] Re: lxc-test-checkpoint-restore fails with no explanation why

2015-11-17 Thread Jeff Lane
Hi,

Not sure this is still an issue, Stephane informed me that those tests
are not meant to be run stand alone and could fail in spectacular ways
when run outside of autopkgtest.

if this is not the case, let me know and when I'm home next week,
I'll dig into this further... otherwise, you can mark this as invalid.

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1514960

Title:
  lxc-test-checkpoint-restore fails with no explanation why

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1514960/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1514942] [NEW] lxc-tests no runtime help (no man page, no --help, etc) for any of the lxc-tests tools

2015-11-10 Thread Jeff Lane
Public bug reported:

I'm investigating lxc-tests and have very little idea what they actually
do.  I had hoped to read a man page, or even just pass --help to them to
get some idea of what each is actually doing.

For example, lxc-test-apparmor, I know it does something with apparmor,
but no idea what.  And as they all seem to ignore --help, I have no idea
at all what it is actually doing.

Please document these tests so users actually understand what they are
testing.  Many tests pass, but some fail, and I really don't know why
they're failing, or what they're even doing in the first place to cause
a fail.

** Affects: lxc (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1514942

Title:
  lxc-tests no runtime help (no man page, no --help, etc) for any of the
  lxc-tests tools

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1514942/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1514961] [NEW] lxc-test-checkpoint-restore doesn't clean up after itself and I am unable to re-run it

2015-11-10 Thread Jeff Lane
Public bug reported:

I ran lxc-test-checkpoint-restore and it failed.  So I decided to try
one additional attempt to verify the failure.  However now I am unable
to re-run the test because apparently the container already exists
(previous test did not clean up after itself), however, lxc list does
not show any running containers...

ubuntu@xwing:~$ lxc list
+--+---+--+--+---+---+
| NAME | STATE | IPV4 | IPV6 | EPHEMERAL | SNAPSHOTS |
+--+---+--+--+---+---+
+--+---+--+--+---+---+
ubuntu@xwing:~$ sudo lxc-test-checkpoint-restore
Container already exists
Failed creating container
ubuntu@xwing:~$ sudo lxc list
+--+---+--+--+---+---+
| NAME | STATE | IPV4 | IPV6 | EPHEMERAL | SNAPSHOTS |
+--+---+--+--+---+---+
+--+---+--+--+---+---+

** Affects: lxc (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1514961

Title:
  lxc-test-checkpoint-restore doesn't clean up after itself and I am
  unable to re-run it

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1514961/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1514950] [NEW] lxc-test-checkpoint-restore can't run because no criu installed

2015-11-10 Thread Jeff Lane
Public bug reported:

on a default 15.10 installation, I have installed lxc-tests and am
running through them individually.

lxc-test-checkpoint-restore fails to run because the package criu is not
installed

ubuntu@xwing:~$ sudo lxc-test-checkpoint-restore
/usr/bin/lxc-test-checkpoint-restore: 22: /usr/bin/lxc-test-checkpoint-restore: 
criu: not found
SKIP: skipping test because no (or wrong) criu installed.

installing lxc-tests should also install any test dependencies like
criu.

** Affects: lxc (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1514950

Title:
  lxc-test-checkpoint-restore can't run because no criu installed

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1514950/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1514960] [NEW] lxc-test-checkpoint-restore fails with no explanation why

2015-11-10 Thread Jeff Lane
Public bug reported:

Ran the ste lxc-test-checkpoint-restore and that failed, but there is no
explanation in the output as to why it failed.  All the output I was
able to create says it created the container fine, but then just failed
for some reason:

I: Configuring libsemanage1:amd64...
I: Configuring libacl1:amd64...
I: Configuring makedev...
I: Configuring bsdutils...
I: Configuring coreutils...
I: Configuring tar...
I: Configuring dpkg...
I: Configuring sed...
I: Configuring perl-base...
I: Configuring grep...
I: Configuring debconf...
I: Configuring tzdata...
I: Configuring gzip...
I: Configuring dash...
I: Configuring sysv-rc...
I: Configuring libpam0g:amd64...
I: Configuring libpam-modules-bin...
I: Configuring bash...
I: Configuring libpam-modules:amd64...
I: Configuring libpam-runtime...
I: Configuring passwd...
I: Configuring login...
I: Configuring adduser...
I: Configuring libuuid1:amd64...
I: Configuring libblkid1:amd64...
I: Configuring libmount1:amd64...
I: Configuring libcryptsetup4:amd64...
I: Configuring mount...
I: Configuring libfdisk1:amd64...
I: Configuring initscripts...
I: Configuring util-linux...
I: Configuring e2fsprogs...
I: Configuring procps...
I: Configuring udev...
I: Configuring systemd...
I: Configuring dmsetup...
I: Configuring systemd-sysv...
I: Configuring init...
I: Configuring libc-bin...
I: Unpacking the base system...
I: Unpacking apt...
I: Unpacking apt-utils...
I: Unpacking busybox-initramfs...
I: Unpacking bzip2...
I: Unpacking console-setup...
I: Unpacking console-setup-linux...
I: Unpacking cpio...
I: Unpacking cron...
I: Unpacking debconf-i18n...
I: Unpacking dh-python...
I: Unpacking eject...
I: Unpacking file...
I: Unpacking gnupg...
I: Unpacking gpgv...
I: Unpacking init-system-helpers...
I: Unpacking initramfs-tools...
I: Unpacking initramfs-tools-bin...
I: Unpacking iputils-ping...
I: Unpacking isc-dhcp-client...
I: Unpacking isc-dhcp-common...
I: Unpacking kbd...
I: Unpacking keyboard-configuration...
I: Unpacking klibc-utils...
I: Unpacking kmod...
I: Unpacking language-pack-en...
I: Unpacking language-pack-en-base...
I: Unpacking less...
I: Unpacking libalgorithm-c3-perl...
I: Unpacking libapt-inst1.7:amd64...
I: Unpacking libapt-pkg4.16:amd64...
I: Unpacking libarchive-extract-perl...
I: Unpacking libatm1:amd64...
I: Unpacking libb-hooks-endofscope-perl...
I: Unpacking libb-hooks-op-check-perl...
I: Unpacking libbareword-filehandles-perl...
I: Unpacking libbsd0:amd64...
I: Unpacking libcgi-fast-perl...
I: Unpacking libcgi-pm-perl...
I: Unpacking libck-connector0:amd64...
I: Unpacking libclass-c3-perl...
I: Unpacking libclass-c3-xs-perl...
I: Unpacking libclass-method-modifiers-perl...
I: Unpacking libclass-xsaccessor-perl...
I: Unpacking libcpan-changes-perl...
I: Unpacking libcpan-meta-perl...
I: Unpacking libdata-optlist-perl...
I: Unpacking libdata-perl-perl...
I: Unpacking libdata-section-perl...
I: Unpacking libdbus-1-3:amd64...
I: Unpacking libdevel-caller-perl...
I: Unpacking libdevel-globaldestruction-perl...
I: Unpacking libdevel-lexalias-perl...
I: Unpacking libdns-export100...
I: Unpacking libdpkg-perl...
I: Unpacking libedit2:amd64...
I: Unpacking libencode-locale-perl...
I: Unpacking libestr0...
I: Unpacking libexporter-tiny-perl...
I: Unpacking libfcgi-perl...
I: Unpacking libffi6:amd64...
I: Unpacking libfile-fcntllock-perl...
I: Unpacking libfile-slurp-perl...
I: Unpacking libfribidi0:amd64...
I: Unpacking libgdbm3:amd64...
I: Unpacking libgetopt-long-descriptive-perl...
I: Unpacking libgmp10:amd64...
I: Unpacking libgnutls-deb0-28:amd64...
I: Unpacking libgnutls-openssl27:amd64...
I: Unpacking libgpm2:amd64...
I: Unpacking libgssapi-krb5-2:amd64...
I: Unpacking libhogweed4:amd64...
I: Unpacking libhtml-parser-perl...
I: Unpacking libhtml-tagset-perl...
I: Unpacking libhttp-date-perl...
I: Unpacking libhttp-message-perl...
I: Unpacking libimport-into-perl...
I: Unpacking libindirect-perl...
I: Unpacking libio-html-perl...
I: Unpacking libio-stringy-perl...
I: Unpacking libirs-export91...
I: Unpacking libisc-export95...
I: Unpacking libisccfg-export90...
I: Unpacking libjson-c2:amd64...
I: Unpacking libk5crypto3:amd64...
I: Unpacking libkeyutils1:amd64...
I: Unpacking libklibc...
I: Unpacking libkrb5-3:amd64...
I: Unpacking libkrb5support0:amd64...
I: Unpacking liblexical-sealrequirehints-perl...
I: Unpacking liblist-moreutils-perl...
I: Unpacking liblocale-gettext-perl...
I: Unpacking liblog-message-perl...
I: Unpacking liblog-message-simple-perl...
I: Unpacking liblwp-mediatypes-perl...
I: Unpacking libmagic1:amd64...
I: Unpacking libmodule-build-perl...
I: Unpacking libmodule-implementation-perl...
I: Unpacking libmodule-pluggable-perl...
I: Unpacking libmodule-runtime-perl...
I: Unpacking libmodule-signature-perl...
I: Unpacking libmoo-perl...
I: Unpacking libmoox-handlesvia-perl...
I: Unpacking libmpdec2:amd64...
I: Unpacking libmro-compat-perl...
I: Unpacking libmultidimensional-perl...
I: Unpacking 

Re: [Bug 1266840] Re: maas-dns failed to install completely on Trusty

2015-11-10 Thread Jeff Lane
On Fri, May 29, 2015 at 7:32 AM, Mario Splivalo
 wrote:
> Hi, Jeff.
>
> Is this still the issue? I just tried deploying maas with ubuntu trusty,
> installing just 'maas' package, which then install everything that was
> needed (incuding maas-dns).  The maas version in trusty is 1.5, and I
> had no issues with installing.
>
> Then I added maas stable ppa, and upgraded to maas 1.7, also no issues.
>
> To be complete, I trashed my test env, created clean one, added maas
> stable ppa and installed maas from there - also no issues.
>
> (I did all my tests in trusty lxc container).
>
> I see you were testing with 1.4+bzr1789+dfsg-0ubuntu1, where maas-dns is
> currenlty on 1.5.

Hi Mario,

No, not for some time.  Indeed this was a 1.4 issue that was resolved
in 1.5.  And to be honest, I don't even bother with anything less than
1.8 these days.  Cert instructs all test centers to install from the
maas/stable ppa, so they get 1.8 out of the box.

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1266840

Title:
  maas-dns failed to install completely on Trusty

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1266840/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1468897] Re: multipath creates binding for Removable(USB) drives

2015-06-30 Thread Jeff Lane
** Tags added: hwcert-server

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to multipath-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1468897

Title:
  multipath creates binding for Removable(USB) drives

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1468897/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1371634] Re: block devices appear twice

2015-06-03 Thread Jeff Lane
Sorry for the vague comment earlier.  What I meant was that, from a
certification point of view, I can't certify a system that ships by
default with dual RAID cards in a multipath configuration when
Multipathing in Ubuntu doesn't work.  That leads to a scenario where,
out of the box on a fresh install you can destroy your own root
filesystem by formatting a drive that you don't realize is actually your
root fs...

In other words, it is very easy to destroy data accidentally if you're
unaware that sde and sda are the same physical device, as you would
reasonably expect those to be separate devices.

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to multipath-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1371634

Title:
  block devices appear twice

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/curtin/+bug/1371634/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1371634] Re: block devices appear twice

2015-06-03 Thread Jeff Lane
I'm setting this to High for now... I really think this is critical as
it is gating the PowerNV certification work.

** Changed in: multipath-tools (Ubuntu)
   Importance: Undecided = High

** Changed in: curtin (Ubuntu)
   Importance: Undecided = High

** Changed in: curtin (Ubuntu)
   Importance: High = Critical

** Changed in: multipath-tools (Ubuntu)
   Importance: High = Critical

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to multipath-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1371634

Title:
  block devices appear twice

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/curtin/+bug/1371634/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1371634] Re: block devices appear twice

2015-06-03 Thread Jeff Lane
Actually, on advice of Andy C, lets go ahead and consider this
critical... this cert needs to be completed as soon as possible and we
can't do that without multipathing working properly.

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to multipath-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1371634

Title:
  block devices appear twice

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/curtin/+bug/1371634/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1381603] Re: Log rotation for maas.log seems broken or non existent

2015-04-22 Thread Jeff Lane
Other logs (pserv and maas-django) rotate, why not maas.log:

drwxr-xr-x  5 maas   maas   4096 Apr 19 07:59 ./
drwxrwxr-x 24 root   syslog 4096 Apr 22 07:55 ../
lrwxrwxrwx  1 root   root 16 Apr  8 15:01 apache2 - /var/log/apache2/
-rw-r--r--  1 maas   maas1092531 Apr 22 08:59 maas-django.log
-rw-r--r--  1 maas   maas  70484 Apr 19 07:59 maas-django.log.1.gz
-rw-r--r--  1 maas   maas  88516 Apr 13 07:36 maas-django.log.2.gz
-rw-r--r--  1 maas   maas  79430 Apr  5 08:01 maas-django.log.3.gz
-rw-r--r--  1 maas   maas  68013 Mar 29 07:57 maas-django.log.4.gz
-rw-r--r--  1 maas   maas  87029 Mar 23 07:35 maas-django.log.5.gz
-rw-r--r--  1 syslog syslog 14951398 Apr 22 09:14 maas.log
drwxrwxr-x 45 maas   maas   4096 Mar  1 08:03 oops/
drwxr-x---  2 proxy  proxy  4096 Apr 22 07:55 proxy/
-rw-r--r--  1 maas   maas   2069 Apr 19 07:59 pserv.log
-rw-r--r--  1 maas   maas   1324 Apr 19 07:59 pserv.log.1.gz
-rw-r--r--  1 maas   maas   5168 Apr 13 07:36 pserv.log.2.gz
-rw-r--r--  1 maas   maas  10722 Apr  5 08:01 pserv.log.3.gz
-rw-r--r--  1 maas   maas   4085 Mar 29 07:57 pserv.log.4.gz
-rw-r--r--  1 maas   maas   1969 Mar 23 07:35 pserv.log.5.gz
drwxr-xr-x  2 syslog syslog 4096 Oct 13  2014 rsyslog/

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1381603

Title:
  Log rotation for maas.log seems broken or non existent

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1381603/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1383727] Re: Fast installer - failure to install grub (UEFI mode)

2015-02-10 Thread Jeff Lane
Just a follow up, when can we expect to see this resolved in Trusty as
we move users/testers over to MAAS 1.7.1 in Trusty?

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to curtin in Ubuntu.
https://bugs.launchpad.net/bugs/1383727

Title:
  Fast installer - failure to install grub (UEFI mode)

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1383727/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1409683] [NEW] Neutron does not refresh mysql connection when HA failover happens

2015-01-12 Thread Jeff Lane
Public bug reported:

Config:

Three MySQL nodes using percona (percona-cluster charm vai juju)
Two Neutron nodes providing network services to an openstack HA deployment (all 
done via juju).

Issue:

While testing failover of MySQL, we noticed that we could no longer
create instances of any sort.  Looking further it looks like neutron-
server can not talk to the mysql server that is currently active (using
the assigned VIP).

Attached is the server log from neutron-server.

Restarting neutron-server resolved the issue for us.

** Affects: neutron (Ubuntu)
 Importance: Undecided
 Status: New

** Attachment added: server.log from neutron-server service
   
https://bugs.launchpad.net/bugs/1409683/+attachment/4296501/+files/neutron-fail.log

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to neutron in Ubuntu.
https://bugs.launchpad.net/bugs/1409683

Title:
  Neutron does not refresh mysql connection when HA failover happens

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/neutron/+bug/1409683/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1274527] Re: MAAS doesn't put its DNS server in resolv.conf

2014-10-24 Thread Jeff Lane
So this bit us again when trying to deploy LDS.  The process there is:

Install/configure MAAs
Populate MAAS
on MAAS, install juju
Juju bootstrap
juju-deployer install LDS
then go to LDS and it does more stuff.

In this case it really caused pain in several cases where juju would say
bootstrap failed (because it was unable to resolve a node name, since
juju bootstrap checks the node hostname rather than the node IP) even
though bootstrap was successful.  I'm sure we probably retried bootstrap
at least 2 - 3 times thinking it had failed when in reality all that had
happened was DNS issues causing the health check to fail.

Also, when trying to deploy stuff to 74 nodes, not being able to access
the node via hostname from the maas server REALLY SUCKED.  It is a pain
to have to click through system pages to find an IP address because
you're unable to ssh node-host-name.maas from MAAS.

It's not a trivial solution, Julian points that out well, but it IS one
that makes debugging and sometimes deployments more painful than they
should be, especially when you're using more than a handful of nodes.

That said, I understand that MAAS is designed to be run distributed
across several bits at scale, but we're taking about DNS.  Perhaps DNS
should be controlled at the region controller level then (If it's not
already, I confess that I don't know where in the stack bind sits in
relation to region-controller, cluster-controller, haproxy, PostgreSQL
and so forth), with each cluster controller updating the region DNS
data, and every cluster passing the region controller as the DNS server
to all nodes as well as using the region controller as the cluster's
primary DNS.  Or at least something like that.

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1274527

Title:
  MAAS doesn't put its DNS server in resolv.conf

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1274527/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1257186] Re: memory leakage messages (no talloc stackframe)

2014-10-08 Thread Jeff Lane
Just adding more griping :) would be nice to see this fixed in Trusty
sometime before next February

bladernr@klaatu:~$ ftp transit
Connected to transit.lanes.
220 (vsFTPd 3.0.2)
Name (transit:bladernr): bladernr
331 Please specify the password.
Password:
no talloc stackframe at ../source3/param/loadparm.c:4864, leaking memory
Login failed.
Remote system type is Login.

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to samba in Ubuntu.
https://bugs.launchpad.net/bugs/1257186

Title:
  memory leakage messages (no talloc stackframe)

To manage notifications about this bug go to:
https://bugs.launchpad.net/samba/+bug/1257186/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1274527] Re: MAAS doesn't put its DNS server in resolv.conf

2014-09-17 Thread Jeff Lane
Maybe I misunderstand the region controller concept or my
understanding of the MAAS ecosystem is outdated.

AIUI there is a region controller that communicates with multiple
cluster controllers that further manage multiple nodes:


  /-- cluster foo - node1.foo, node2.foo, node3.foo ... nodeX.foo
/
region -- cluster bar - node1.bar, node2.bar, node3.bar ... nodeX.bar
   \
\-- cluster baz - node1.baz, node2.baz, node3.baz, ... nodeX.baz

Is that incorrect?  That's what I meant when I said region controller
my point was just in agreement that whatever entity controls DNS for
the MAAS environment should be aware and able to resolve it's own DNS
within the MAAS environment.

Part of my confusion is that I lack the hardware to do a config where I
install maas-region-controller on one machine and maas-cluster-
controller on another and then add nodes to see where things fall.  It's
a very complex system and there are gaps in my view of how it all plays
together.


Additionally this DID create an issue with juju as I did a juju bootstrap on my 
only maas server to bootstrap my only node.  Node booted and deployed and 
bootstrapped BUT when I attempted a 'juju ssh 0' to ssh to the bootstrap node, 
that failed because juju was trying to access the FQDN of node0, NOT it's IP 
address.

So even though MAAS set the FQDN of the node (supermicro.master in this
case) the inability to resolve those names inside the MAAS environment
caused juju to be unable to contact those nodes/units.  This was easily
resolved by editing /etc/resolv.conf on my MAAS server (it contains
everything, maas-region-controller, maas-cluster-controller and ALL
dependencies and ancillary packages/services AND all the juju stuff as
well) and making sure my MAAS server could use it's own instance of bind
for DNS resolution.

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1274527

Title:
  MAAS doesn't put its DNS server in resolv.conf

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1274527/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1274527] Re: MAAS doesn't put its DNS server in resolv.conf

2014-09-11 Thread Jeff Lane
Additionally, do we not also use juju, region and cluster on the same
NUC inside the Orange Box?  So it seems like it would be important from
the OB perspective to fix this as well.  Just an additional use case.

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1274527

Title:
  MAAS doesn't put its DNS server in resolv.conf

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1274527/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1274527] Re: MAAS doesn't put its DNS server in resolv.conf

2014-09-11 Thread Jeff Lane
Hrmmm... it just bit me while trying to test out the checkbox charm on
bare metal from my private maas server.  and it's not just a matter of
juju.

for example, MAAS is successfully updating the zone files:

npdxh IN CNAME 10-0-0-123

and I can't ssh to my node by hostname:
ubuntu@critical-maas:/etc/bind/maas$ ssh npdxh
ssh: Could not resolve hostname npdxh: Name or service not known

so I have to know the IP address.

The NODE, does at least resolve DNS on the MAAS network properly:
ubuntu@npdxh:~$ host npdxh
npdxh.master is an alias for 10-0-0-123.master.
10-0-0-123.master has address 10.0.0.123

And I'm sure we all already know that much.

IN any case, this is an annoyance, it's fixable, but really, the MAAS
region controller (and cluster in this case since they're all one system
for me) should be able to resolve its own DNS entries.

From a more important use case, for certification purposes, if I am
going to get testers to use juju and the checkbox charms for testing, I
can not also require them to provide separate systems to serve as region
or cluster or juju systems just for DNS resolution to work.  Nor does it
look good to tell engineers at partner sites to manually work around
this.

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1274527

Title:
  MAAS doesn't put its DNS server in resolv.conf

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1274527/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1359409] Re: ipmi-locate only works on ia64

2014-08-26 Thread Jeff Lane
FWIW, this does not seem to be universal to UEFI systems.  I've
performed enlistment and commissioning on several IBM systems in full
UEFI mode that behaved just fine (and a couple new density systems that
showed the same sort of issue Narninder mentions here).

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to freeipmi in Ubuntu.
https://bugs.launchpad.net/bugs/1359409

Title:
  ipmi-locate only works on ia64

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/freeipmi/+bug/1359409/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1304518] Re: Confusing wording in the IPMI section of node power data

2014-05-06 Thread Jeff Lane
Yeah, that could work.

** Changed in: maas
   Status: Incomplete = Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1304518

Title:
  Confusing wording in the IPMI section of node power data

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1304518/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1304518] Re: Confusing wording in the IPMI section of node power data

2014-04-22 Thread Jeff Lane
Julian:  THAT makes more sense... perhaps this would be less confusing,
from a user standpoint:

MAC Address - Enter the BMC's MAC Address here if you are NOT using DHCP
to assign BMC IP Addresses

** Changed in: maas
   Status: Incomplete = New

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1304518

Title:
  Confusing wording in the IPMI section of node power data

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1304518/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1304613] Re: nodes can't get out to the internet beyond the maas server by default

2014-04-22 Thread Jeff Lane
Hi Julian,

I've got several MAAS servers that seem to suffer the same fate,
depending on what your definition of Access the internet is.

We first saw this at the Orange Box sprint in london where nodes could
be deployed via d-i which was pulling packages from MAAS's squid-deb-
proxy, IIRC, however they couldn't pull packages afterwards from
ppa.launchpad.net or the internet in general (e.g. I couldn't ssh to a
node and they wget a file from somewhere else).

A good example of this was when we tried usign juju to deploy certain
charms that pull from places like github, the charms would fail because
those sites were unreachable from the node itself (but not from the MAAS
Server).  So we configured NAT to allow the nodes to pass through to the
internet to reach anywhere.

In our immediate case with certification, we have several NUCs that are
configured as MAAS servers for deploying both the OS and certification
tools.

So here is IP Tables after a fresh reboot of my NUC running the latest 14.04 
MAAS:
ubuntu@critical-maas:~$ sudo iptables -L
[sudo] password for ubuntu: 
Chain INPUT (policy ACCEPT)
target prot opt source   destination 

Chain FORWARD (policy ACCEPT)
target prot opt source   destination 

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination 
ubuntu@critical-maas:~$ sudo iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target prot opt source   destination 

Chain INPUT (policy ACCEPT)
target prot opt source   destination 

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination 

Chain POSTROUTING (policy ACCEPT)
target prot opt source   destination 
ubuntu@critical-maas:~$ 
ubuntu@critical-maas:~$ COLUMNS=150 dpkg -l |grep maas
ii  maas1.5+bzr2252-0ubuntu1 all  
MAAS server all-in-one metapackage
ii  maas-cli1.5+bzr2252-0ubuntu1 all  
MAAS command line API tool
ii  maas-cluster-controller 1.5+bzr2252-0ubuntu1 all  
MAAS server cluster controller
ii  maas-common 1.5+bzr2252-0ubuntu1 all  
MAAS server common files
ii  maas-dhcp   1.5+bzr2252-0ubuntu1 all  
MAAS DHCP server
ii  maas-dns1.5+bzr2252-0ubuntu1 all  
MAAS DNS server
ii  maas-region-controller  1.5+bzr2252-0ubuntu1 all  
MAAS server complete region controller
ii  maas-region-controller-min  1.5+bzr2252-0ubuntu1 all  
MAAS Server minimum region controller
ii  maas-test   0.1+bzr147+150+10~pp all  
Utility to test hardware compatibility with MAAS
ii  python-django-maas  1.5+bzr2252-0ubuntu1 all  
MAAS server Django web framework
ii  python-maas-client  1.5+bzr2252-0ubuntu1 all  
MAAS python API client
ii  python-maas-provisioningserver  1.5+bzr2252-0ubuntu1 all  
MAAS server provisioning libraries

Now I have the server installed and try a couple things to see if my node can 
talk to the internet:
ubuntu@supermicro:~$ host ubuntu.com
ubuntu.com has address 91.189.94.156
ubuntu.com mail is handled by 10 mx.canonical.com.

ubuntu@supermicro:~$ sudo ping -c 10 www.ubuntu.com
PING www.ubuntu.com (91.189.89.103) 56(84) bytes of data.

--- www.ubuntu.com ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 9071ms

I am able to install something:
ubuntu@supermicro:~$ sudo apt-get install ksh
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following NEW packages will be installed:
  ksh
0 upgraded, 1 newly installed, 0 to remove and 3 not upgraded.
Need to get 1,583 kB of archives.
After this operation, 3,229 kB of additional disk space will be used.
Get:1 http://archive.ubuntu.com//ubuntu/ trusty/universe ksh amd64 
93u+20120801-1 [1,583 kB]
Fetched 1,583 kB in 7s (223 kB/s)   
 
Selecting previously unselected package ksh.
(Reading database ... 69996 files and directories currently installed.)
Preparing to unpack .../ksh_93u+20120801-1_amd64.deb ...
Unpacking ksh (93u+20120801-1) ...
Processing triggers for man-db (2.6.7.1-1) ...
Setting up ksh (93u+20120801-1) ...
update-alternatives: using /bin/ksh93 to provide /bin/ksh (ksh) in auto mode

but is that going through the squid deb proxy?

Because I am unable to manually touch archive.ubuntu.com:
--2014-04-22 18:38:29--  
http://archive.ubuntu.com/ubuntu/pool/universe/k/ksh/ksh_93u+20120801-1_amd64.deb
Resolving archive.ubuntu.com (archive.ubuntu.com)... 91.189.92.200, 
91.189.91.13, 91.189.91.14, ...
Connecting to archive.ubuntu.com 

[Bug 1304613] Re: nodes can't get out to the internet beyond the maas server by default

2014-04-22 Thread Jeff Lane
Then again, perhaps something as simple as a 'maas-enable-nat' command
for these simple cases would be sufficient so new users don't have to
also understand iptables... and makes it optional on the maas server so
you can or can not enable it...  maybe it is a per-cluster-controller
thing, as my understanding is that the region controller just handles
certain things whie the clusters do the bulk of the work for the
nodes...

I dont have the hardware really to set up a different cluster
controller... for now.

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1304613

Title:
  nodes can't get out to the internet beyond the maas server by default

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1304613/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1304613] Re: nodes can't get out to the internet beyond the maas server by default

2014-04-22 Thread Jeff Lane
As for your question about the region... I don't know... that's
operating at scale.  The question there is probably one of hierarchy...
for example, would you have multiple, linked region controllers, or more
like a few region controllers and several cluster controllers under
each?

And in that case, perhaps you'd want to be able to arbitrarily set this
assuming each region and cluster controller is a physical machine:

Region1 -- Dashboard -- cluster 1
 |-- cluster 2
 |-- cluster 3
 |-- cluster 4
  |---node 1
  |---node 2
  |---node X

So perhaps you would want to be able to, via the dashboard, or some
other means say, Cluster 1 shoud be segregated and never pass packets
out, but cluster 4 are all web-servers and associated servers and DO
need to be able to send and recieve from the internet and cluster 3
contains the things teh web servers need on the back end (SQL, etc) so
Cluster 3 should only talk to cluster 4 and NEVER talk to the internet.

Or I don't know, that's really a VERY ugly example.

My original point was just that, by default on my very simple use case
(and also as seen with the Orange Boxes), the deployed nodes can't talk
to the internet without some manual futzing behind the scenes, and
there's no simple way to fix that if you don't know iptables scripting
and what bits to flip.

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1304613

Title:
  nodes can't get out to the internet beyond the maas server by default

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1304613/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1309761] [NEW] MAAS installing older 14.04 image instead of newer one

2014-04-18 Thread Jeff Lane
Public bug reported:

I have a NUC with the current version of 14.04 and MAAS installed on it.

Today, I completely removed the contents of boot-resources and re-
imported the various boot/image files to remove old daily images and
older versions I didn't need.

If you look at the current image streams dir at maas-images.ubuntu.com,
you'll see that there are actually two image versions for trusty:

Index of /images/ephemeral-v2/releases/trusty/amd64

NameLast modified   SizeDescription
Parent Directory -   
20140410/   10-Apr-2014 22:22-   
20140416.1/ 17-Apr-2014 18:22-   
di/ 17-Apr-2014 18:22-   

The older 0410 image is the RC image and the newer 0416.1 image is the
release version of 14.04.

Because of this, the current snapshot has both images available:
ubuntu@critical-maas:/var/lib/maas/boot-resources/current/amd64/generic/trusty$ 
ls -l *
rc:
total 1812444
-rw-r--r-- 2 root root   24654011 Apr 18 12:57 boot-initrd
-rw-r--r-- 2 root root5774304 Apr 18 12:57 boot-kernel
-rw-r--r-- 2 root root   21256334 Apr 18 12:58 di-initrd
-rw-r--r-- 2 root root5776216 Apr 18 12:57 di-kernel
-rw-r--r-- 2 root root 1476395008 Apr 18 12:56 root-image
-rw-r--r-- 2 root root  322069555 Apr 18 12:57 root-tgz

release:
total 1812428
-rw-r--r-- 2 root root   24663072 Apr 18 12:50 boot-initrd
-rw-r--r-- 2 root root5777056 Apr 18 12:49 boot-kernel
-rw-r--r-- 2 root root   21256771 Apr 18 12:50 di-initrd
-rw-r--r-- 2 root root5778968 Apr 18 12:50 di-kernel
-rw-r--r-- 2 root root 1476395008 Apr 18 12:49 root-image
-rw-r--r-- 2 root root  322042698 Apr 18 12:49 root-tgz

And MAAS shows both the RC and Release images available as bootable for
Trusty (**See attached screen shot**)

However, in the MAAS ui, the ONLY option for setting the installation
image is Trusty there is no setting for choosing between RC and
Release images for Trusty.

And MAAS is choosing to install the older version when booting.

I noticed quickly during boot that my node is getting the rc image via
iscsi... but have no way of capturing that other than maybe a crappy
cell phone image..., so the following will have to suffice:

Installing using the fast path, MAAS is choosing the older 0410 RC
images over the 0416.1 Release images, and we get a system installed
with the Development version of Trusty instead, as bore out by the
kernel version and /etc/lsb-release. Here's some data from a node
installed via FastPath:

ubuntu@supermicro:~$ uname -a
Linux supermicro 3.13.0-23-generic #45-Ubuntu SMP Fri Apr 4 06:58:38 UTC 2014 
x86_64 x86_64 x86_64 GNU/Linux
ubuntu@supermicro:~$ cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION=Ubuntu Trusty Tahr (development branch)

This is immediately following a fast-path install of Trusty.

I'm now trying to do a d-i install, which worked before I deleted and
re-imported but that is now failing with the No kernel modules found
message and looking at alternate consoles, that too appears to be the
3.13.0-23 boot image, not the 3.13.0-24 image... so that could be the
issue there...  not sure though.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: maas 1.5+bzr2252-0ubuntu1
ProcVersionSignature: Ubuntu 3.13.0-24.46-generic 3.13.9
Uname: Linux 3.13.0-24-generic x86_64
ApportVersion: 2.14.1-0ubuntu3
Architecture: amd64
Date: Fri Apr 18 16:58:55 2014
InstallationDate: Installed on 2014-01-13 (95 days ago)
InstallationMedia: Ubuntu 14.04 LTS Trusty Tahr - Alpha amd64 (20140113)
PackageArchitecture: all
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=set
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: maas
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: maas (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug trusty

** Attachment added: maas-re-import.png
   
https://bugs.launchpad.net/bugs/1309761/+attachment/4088105/+files/maas-re-import.png

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1309761

Title:
  MAAS installing older 14.04 image instead of newer one

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1309761/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1309761] Re: MAAS installing older 14.04 image instead of newer one

2014-04-18 Thread Jeff Lane
I went through and deleted the rc directory from *current, and also
deleted the individual images themselves (had to compare inode numbers
in rc/ to the images in cache and deleted the images individually by
inode.

Then I did an install and it installed the correct image by default:

ubuntu@supermicro:~$ uname -a
Linux supermicro 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014 
x86_64 x86_64 x86_64 GNU/Linux
ubuntu@supermicro:~$ cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION=Ubuntu 14.04 LTS

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1309761

Title:
  MAAS installing older 14.04 image instead of newer one

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1309761/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1309761] Re: MAAS installing older 14.04 image instead of newer one

2014-04-18 Thread Jeff Lane
So it would seem to confirm that MAAS is choosing the older 20140410
images over the 20140416.1 images when installing.

This is my bootresources.yaml: (The only changes I made were commenting
out older versions I didn't want to pull down)

ubuntu@critical-maas:/var/lib/maas/boot-resources$ cat 
/etc/maas/bootresources.yaml
##
## Boot image download configuration.
##
#
# Items in this configuration:
#
# boot - the root for these settings.
#
#   storage - location on the filesystem where boot images are stored.
#
# These images can get quite large: some files are hundreds of megabytes,
# and you may need multiple copies for different architectures, OS releases,
# etc.
#
#   sources - one or more sources of downloadable boot images.
#
# Each source downloads from one simplestreams URL, though it is possible to
# have multiple sources using the same URL.
#
# path - for each source, the path to its (online) Simplestreams data.
#
# keyring - for each source, a GPG keyring to verify images' signatures.
#
# selections - for each source, one or more sets of constraints for images.
#
# From each source, only those images are imported which match at least one of
# the source's selections.  A selection can specify an OS release, a CPU
# architecture, and so on.
#
# Be careful: the items in a selection will multiply.  For example if you
# specify architectures i386 and amd64, and subarchitectures generic,
# hwe-s, and hwe-t, the import script will need to import 6 images, for
# each possible combination.  If you only want some of those combinations,
# keep them as separate sources and/or selections.

boot:
  sources:
  - keyring: /usr/share/keyrings/ubuntu-cloudimage-keyring.gpg
path: http://maas.ubuntu.com/images/ephemeral-v2/releases/
selections:
#- arches:
#  - amd64
#  release: lucid
#  subarches:
#  - generic
#- arches:
#  - amd64
#  release: precise
#  subarches:
#  - generic
#- arches:
#  - amd64
#  release: quantal
#  subarches:
#  - generic
#- arches:
#  - amd64
#  release: raring
#  subarches:
#  - generic
- arches:
  - amd64
  release: saucy
  subarches:
  - generic
- arches:
  - amd64
  release: trusty
  subarches:
  - generic
#- arches:
#  - armhf
#  release: precise
#  subarches:
#  - generic
#- arches:
#  - armhf
#  release: quantal
#  subarches:
#  - generic
#- arches:
#  - armhf
#  release: raring
#  subarches:
#  - generic
#- arches:
#  - armhf
#  release: saucy
#  subarches:
#  - generic
#- arches:
#  - armhf
#  release: trusty
#  subarches:
#  - generic
#- arches:
#  - armhf
#  release: precise
#  subarches:
#  - highbank
#- arches:
#  - armhf
#  release: quantal
#  subarches:
#  - highbank
#- arches:
#  - armhf
#  release: raring
#  subarches:
#  - highbank
#- arches:
#  - armhf
#  release: trusty
#  subarches:
#  - highbank
#- arches:
#  - i386
#  release: lucid
#  subarches:
#  - generic
#- arches:
#  - i386
#  release: precise
#  subarches:
#  - generic
#- arches:
#  - i386
#  release: quantal
#  subarches:
#  - generic
#- arches:
#  - i386
#  release: raring
#  subarches:
#  - generic
- arches:
  - i386
  release: saucy
  subarches:
  - generic
- arches:
  - i386
  release: trusty
  subarches:
  - generic
  storage: /var/lib/maas/boot-resources/

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1309761

Title:
  MAAS installing older 14.04 image instead of newer one

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1309761/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1304518] [NEW] Confusing wording in the IPMI section of node power data

2014-04-08 Thread Jeff Lane
Public bug reported:

New to the power management part of node info is this text:

MAC address - the IP is looked up with ARP and is used if IP address is
empty. This is better when the BMC uses DHCP.

What is better when the BMC uses DHCP?  Does using DHCP make using ARP
better?  or more accurate?

I can't really seem to grok what this explanation of MAC Address
actually means.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: maas 1.5+bzr2227-0ubuntu1
ProcVersionSignature: Ubuntu 3.13.0-23.45-generic 3.13.8
Uname: Linux 3.13.0-23-generic x86_64
ApportVersion: 2.14.1-0ubuntu1
Architecture: amd64
Date: Tue Apr  8 12:09:59 2014
InstallationDate: Installed on 2014-01-13 (84 days ago)
InstallationMedia: Ubuntu 14.04 LTS Trusty Tahr - Alpha amd64 (20140113)
PackageArchitecture: all
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=set
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: maas
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: maas (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug trusty

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1304518

Title:
  Confusing wording in the IPMI section of node power data

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1304518/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1304613] [NEW] nodes can't get out to the internet beyond the maas server by default

2014-04-08 Thread Jeff Lane
Public bug reported:

by default, there's no way for a node started by maas to talk to the
internet.   There is also no way on the maas dashboard that I can see
that allows me to control this sort of network behaviour either.

For now, we are using a shell script to start NAT rules in iptables so
that a node can actually talk to the internet.

Scenario one:

node commissioned and started, uses d-i to do a basic install.  This
works fine however, if you have the pressed do something like add a PPA
for some different packages during late_command, you can never complete
installation because add-apt-repository can't talk to the outside.  And
if you add the repo manually, I do not believe you can actually pull the
packages from ppa.launchpad.net.

Scenario two:
node commissioned and started, using fast-path install.  After fast-path is 
done and note reboots, you ssh into the node and want to add the PPA manually 
and install packages.  This is impossible because again, add-apt-repository 
fails to get stuff from launchpad.net.

Solution to both, for now, is to set up NAT with the following rules:

echo 1  /proc/sys/net/ipv4/ip_forward
/sbin/iptables -t nat -A POSTROUTING -o $EXTERNAL -j MASQUERADE
/sbin/iptables -A FORWARD -i $EXTERNAL -o $INTERNAL -m state --state 
RELATED,ESTABLISHED -j ACCEPT
/sbin/iptables -A FORWARD -i $INTERNAL -o $EXTERNAL -j ACCEPT

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: maas 1.5+bzr2227-0ubuntu1
ProcVersionSignature: Ubuntu 3.13.0-23.45-generic 3.13.8
Uname: Linux 3.13.0-23-generic x86_64
ApportVersion: 2.14.1-0ubuntu1
Architecture: amd64
Date: Tue Apr  8 15:11:12 2014
InstallationDate: Installed on 2014-01-13 (85 days ago)
InstallationMedia: Ubuntu 14.04 LTS Trusty Tahr - Alpha amd64 (20140113)
PackageArchitecture: all
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=set
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: maas
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: maas (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug trusty

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1304613

Title:
  nodes can't get out to the internet beyond the maas server by default

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1304613/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1294332] [NEW] MAAS fails to manage power for system with Intel Integrated BMC

2014-03-18 Thread Jeff Lane
Public bug reported:

I have a system with an intel iBMC onboard.

MAAS can successfully create the maas user and add/change the password,
and it also has the correct administrator priviliges.

MAAS also created the user in slot 6, the first available, rather than
choking on slot 4 or 10.

HOWEVER, any time I try to use MAAS to actually power the machine on, I
see a traceback in the celery log and the system fails to come on.

I CAN, however, control the system via IPMI directly (ipmitool) to bring
it up or down.

MAAS sets the power for this system to IPMI 2.0

Here's the traceback from celery.log, not that it's terribly informative:
[2014-03-18 15:32:34,605: ERROR/MainProcess] Task 
provisioningserver.tasks.power_off[868fef2b-8335-449d-a18f-8ef8307bdce2] raised 
unexpected: PowerActionFail()
Traceback (most recent call last):
  File /usr/lib/python2.7/dist-packages/celery/app/trace.py, line 218, in 
trace_task
R = retval = fun(*args, **kwargs)
  File /usr/lib/python2.7/dist-packages/celery/app/trace.py, line 398, in 
__protected_call__
return self.run(*args, **kwargs)
  File /usr/lib/python2.7/dist-packages/provisioningserver/tasks.py, line 
161, in power_off
issue_power_action(power_type, 'off', **kwargs)
  File /usr/lib/python2.7/dist-packages/provisioningserver/tasks.py, line 
141, in issue_power_action
pa.execute(**kwargs)
  File 
/usr/lib/python2.7/dist-packages/provisioningserver/power/poweraction.py, 
line 132, in execute
rendered = self.render_template(template, **kwargs)
  File 
/usr/lib/python2.7/dist-packages/provisioningserver/power/poweraction.py, 
line 107, in render_template
raise PowerActionFail(self, error)
PowerActionFail

I also attempted to set the power type to PMI 1.5 and that too produced
the same traceback and failure to power on.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: maas 1.5+bzr1977-0ubuntu5
ProcVersionSignature: Ubuntu 3.13.0-18.38-generic 3.13.6
Uname: Linux 3.13.0-18-generic x86_64
ApportVersion: 2.13.3-0ubuntu1
Architecture: amd64
CurrentDesktop: Unity
Date: Tue Mar 18 15:28:09 2014
InstallationDate: Installed on 2014-01-13 (64 days ago)
InstallationMedia: Ubuntu 14.04 LTS Trusty Tahr - Alpha amd64 (20140113)
PackageArchitecture: all
SourcePackage: maas
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: maas (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug trusty

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1294332

Title:
  MAAS fails to manage power for system with Intel Integrated BMC

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1294332/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1294332] Re: MAAS fails to manage power for system with Intel Integrated BMC

2014-03-18 Thread Jeff Lane
I also manually tried using the ipmipower command in addition to
ipmitool:

ubuntu@critical-maas:~$ ipmipower -h 10.0.0.125 -u maas -p TRRnqoEl9ccQy7 --off
10.0.0.125: ok
ubuntu@critical-maas:~$ ipmipower -h 10.0.0.125 -u maas -p TRRnqoEl9ccQy7 
--on-if-off --cycle
10.0.0.125: ok

both of these commands were successfully executed from CLI.

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1294332

Title:
  MAAS fails to manage power for system with Intel Integrated BMC

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1294332/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1294332] Re: MAAS fails to manage power for system with Intel Integrated BMC

2014-03-18 Thread Jeff Lane
Since apport didn't gather any maas logs, here they are...

** Attachment added: maas-logs.tar.gz
   
https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1294332/+attachment/4031166/+files/maas-logs.tar.gz

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1294332

Title:
  MAAS fails to manage power for system with Intel Integrated BMC

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1294332/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1270165] [NEW] Stop action does not power systems down

2014-01-17 Thread Jeff Lane
Public bug reported:

I had three servers connected to my MAAS server.  All three were
successfully enlisted, commissioned and in the Ready state.

I did a juju bootstrap which grabbed one server, powered it on and
installed and completed Juju's bootstrap bringup.  This was confirmed by
running juju status.

I next wanted to confirm I could install a system directly from MAAS by
simply issuing the Start node action.  So I selected one free node and
clicked the Start node button in the nodes details page.

This turned the node on, and it did indeed install the prescribed OS
version.

Now, I wanted to release those for use elsewhere, so in the Nodes page,
I selected my juju bootstrap node and my recently installed generic node
(both in the Alloctated to ubuntu state, ubuntu is the username) and
then in the Bulk Actions dropdown selected Stop selected nodes and
clicked the Go button.

At this point, the MAAS UI refreshed and showed the systems back in the
Ready unallocated state, indicating that I could proceed to re-enlist
them.  However, neither of the nodes actually powered off.

This means I will be unable to re-use those nodes without manually
powering them off.

To check this, I left them in their Powered On but Ready in MAAS state
and attempted to Start one wiht a different Ubuntu version chosen for
it.

As predicted, the node did not reboot, reset or anything, meaning it was
still running in it's previous state, regardless of what MAAS or I
wanted it to do.  I had to manually reset teh system to get it to come
back up and PXE boot the new OS from MAAS.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: maas 1.4+bzr1817+dfsg-0ubuntu1
ProcVersionSignature: Ubuntu 3.13.0-2.17-generic 3.13.0-rc7
Uname: Linux 3.13.0-2-generic x86_64
ApportVersion: 2.13.1-0ubuntu1
Architecture: amd64
CurrentDesktop: Unity
Date: Thu Jan 16 09:49:57 2014
InstallationDate: Installed on 2014-01-13 (2 days ago)
InstallationMedia: Ubuntu 14.04 LTS Trusty Tahr - Alpha amd64 (20140113)
PackageArchitecture: all
SourcePackage: maas
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: maas (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug trusty

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1270165

Title:
  Stop action does not power systems down

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1270165/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1268795] Re: unable to automatically commission Cisco UCS server due to BMC user permissions

2014-01-15 Thread Jeff Lane
Yep, that was the workaround I used.

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1268795

Title:
  unable to automatically commission Cisco UCS server due to BMC user
  permissions

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1268795/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1269046] [NEW] Nodes created manually and then enlisted are forgotten by MAAS

2014-01-14 Thread Jeff Lane
Public bug reported:

On my MAAS box running trusty:

In the MAAS UI, we created a node entry for a server, choosing IPMI and
passing the login credentials, IP for the BMC and the MAC address.  On
saving the node, MAAS issued the IPMI command to turn the server on.

The server successfully powered on and PXE booted the enlistment image.
Once enlistment was complete, the server powered off.

On refreshing the MAAS UI, however, the original node we created
manually was shown still in the Commissioning state.

A NEW node was also listed, showing it was in the Delcared state.

What seems to have happened is that MAAS, instead of filling data for
the node we created manually, just created a brand new node instead, and
ignored ours.

The original manual node can be safely deleted.

POSSIBLE CAUSE:
When we created the node originally in the UI, we passed it the MAC address for 
the BMC port.
The newly created node, however, lists the MAC addresses for all onboard 
ethernet ports, NOT the management port.

If the MAC address part of the Add Node page means MAC for the ethernet
device that PXE boots, the page is misleading and needs to be corrected.

As it stands, I thought that MAC entry was supposed to be for the BMC
MAC address.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: maas 1.4+bzr1789+dfsg-0ubuntu1
ProcVersionSignature: Ubuntu 3.13.0-2.17-generic 3.13.0-rc7
Uname: Linux 3.13.0-2-generic x86_64
ApportVersion: 2.13.1-0ubuntu1
Architecture: amd64
CurrentDesktop: Unity
Date: Tue Jan 14 10:51:05 2014
InstallationDate: Installed on 2014-01-13 (0 days ago)
InstallationMedia: Ubuntu 14.04 LTS Trusty Tahr - Alpha amd64 (20140113)
PackageArchitecture: all
SourcePackage: maas
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: maas (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug trusty

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1269046

Title:
  Nodes created manually and then enlisted are forgotten by MAAS

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1269046/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1268713] [NEW] import-boot-images doesn't seem to do anything on latest trusty builds

2014-01-13 Thread Jeff Lane
Public bug reported:

Following the docs, I did the following on a system running the latest
Trusty image with the latest MAAS packages for trusty:

$ maas-cli maas node-groups import-boot-images

On Saucy or earlier (and I believe on earlier versions of Trusty), this
would launch the olders scripts maas-import-pxe-files and maas-import-
ephemerals

Today, it does nothing but exit.  Nothign appears in the pserv log,
nothing in maas.log.

There is nothing I can find written anywhere that indicates this command
is doing anything other than printing the message that the files will be
imported and then exiting.

There is no data being written to the /var/lib/maas/ dirs that hold
ephemerals and PXE files and nothing appears in PS to be related to
this.

I finally manually ran the older commands to get the files imported.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: maas 1.4+bzr1789+dfsg-0ubuntu1
ProcVersionSignature: Ubuntu 3.13.0-2.17-generic 3.13.0-rc7
Uname: Linux 3.13.0-2-generic x86_64
ApportVersion: 2.13.1-0ubuntu1
Architecture: amd64
CurrentDesktop: Unity
Date: Mon Jan 13 15:06:07 2014
InstallationDate: Installed on 2014-01-13 (0 days ago)
InstallationMedia: Ubuntu 14.04 LTS Trusty Tahr - Alpha amd64 (20140113)
PackageArchitecture: all
SourcePackage: maas
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: maas (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug trusty

** Summary changed:

- import-boot-images doesn't seem to do anything
+ import-boot-images doesn't seem to do anything on latest trusty builds

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1268713

Title:
  import-boot-images doesn't seem to do anything on latest trusty builds

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1268713/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1268783] [NEW] traceback in celery-region log when maas controls DNS and tries to write dns config

2014-01-13 Thread Jeff Lane
Public bug reported:

Using latest trusty bits I manually created a node in the MAAS UI.  On
setting the node, MAAS successfully powered the node on via IPMI.  The
node booted and got an IP address but then failed to PXE due to PXE
timeout errors.  While all this is going on, each retry prompted a new
DHCP lease which seems to have triggered a DNS update.  The celery
region log showed this each time DNS config was attempted:

[2014-01-13 18:26:20,751: INFO/MainProcess] Got task from broker: 
provisioningserver.tasks.write_full_dns_config[f67e9cfd-34e5-4cf8-abf1-b01d4ea01919]
[2014-01-13 18:26:20,791: INFO/MainProcess] Task 
provisioningserver.tasks.write_full_dns_config[f67e9cfd-34e5-4cf8-abf1-b01d4ea01919]
 succeeded in 0.0343019962311s: None
[2014-01-13 18:26:20,797: INFO/MainProcess] Got task from broker: 
provisioningserver.tasks.rndc_command[0f41c14f-5d56-4811-9743-359451260a06]
[2014-01-13 18:26:20,834: ERROR/MainProcess] Task 
provisioningserver.tasks.rndc_command[0f41c14f-5d56-4811-9743-359451260a06] 
raised exception: UnpickleableExceptionWrapper('provisioningserver.utils', 
'ExternalProcessError', (), 'ExternalProcessError()')
Traceback (most recent call last):
  File /usr/lib/python2.7/dist-packages/celery/execute/trace.py, line 181, in 
trace_task
R = retval = fun(*args, **kwargs)
  File /usr/lib/python2.7/dist-packages/provisioningserver/tasks.py, line 
186, in rndc_command
execute_rndc_command(arguments)
  File /usr/lib/python2.7/dist-packages/provisioningserver/dns/config.py, 
line 152, in execute_rndc_command
call_and_check(rndc_cmd, stdout=devnull)
  File /usr/lib/python2.7/dist-packages/provisioningserver/utils.py, line 
119, in call_and_check
return subprocess.check_call(command, *args, **kwargs)
  File /usr/lib/python2.7/subprocess.py, line 540, in check_call
raise CalledProcessError(retcode, cmd)
ExternalProcessError: ExternalProcessError()

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: maas 1.4+bzr1789+dfsg-0ubuntu1
ProcVersionSignature: Ubuntu 3.13.0-2.17-generic 3.13.0-rc7
Uname: Linux 3.13.0-2-generic x86_64
ApportVersion: 2.13.1-0ubuntu1
Architecture: amd64
CurrentDesktop: Unity
Date: Mon Jan 13 18:35:55 2014
InstallationDate: Installed on 2014-01-13 (0 days ago)
InstallationMedia: Ubuntu 14.04 LTS Trusty Tahr - Alpha amd64 (20140113)
PackageArchitecture: all
SourcePackage: maas
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: maas (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug trusty

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1268783

Title:
  traceback in celery-region log when maas controls DNS and tries to
  write dns config

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1268783/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1268795] [NEW] unable to automatically commission Cisco UCS server due to BMC user permissions

2014-01-13 Thread Jeff Lane
Public bug reported:

I have connected a Cisco UCS C220 M3 system to my MAAS server.

I have tried and succeeded in enlisting the server both automatically by
powering the server on manually, and via the UI by feeding maas the
server CIMC information and have MAAS automatically power the server on
via IPMI and enlist.

BUT once I get to a declared system, I am unable to commission it via
the UI.

When the system is enlisted, MAAS appears to create a maas user in slot
10 of the CIMC user table.  BUT rather than making this user a User or
Admin, it is set to Read Only

Because of this, the maas user in the CIMC does not have permission to
power the server up or down and thus can't commission.

If I manually power the server on, it then PXE bootes the commissioning
image, does it's stuff and then shuts down.

At this point, the server is indeed marked as Ready and can be used in
the MAAS cluster.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: maas 1.4+bzr1789+dfsg-0ubuntu1
ProcVersionSignature: Ubuntu 3.13.0-2.17-generic 3.13.0-rc7
Uname: Linux 3.13.0-2-generic x86_64
ApportVersion: 2.13.1-0ubuntu1
Architecture: amd64
CurrentDesktop: Unity
Date: Mon Jan 13 19:25:55 2014
InstallationDate: Installed on 2014-01-13 (0 days ago)
InstallationMedia: Ubuntu 14.04 LTS Trusty Tahr - Alpha amd64 (20140113)
PackageArchitecture: all
SourcePackage: maas
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: maas (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug trusty

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1268795

Title:
  unable to automatically commission Cisco UCS server due to BMC user
  permissions

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1268795/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1266840] Re: maas-dns failed to install completely on Trusty

2014-01-10 Thread Jeff Lane
https://bugs.launchpad.net/maas/+bug/1035998/comments/2

Reading that comment, it suggests that the named.conf.maas file should
be empty by design so I created one like so:

sudo touch /etc/named/maas/named.conf.maas

and restarted bind and apache.

Then, I deleted my node and retried and it successfully commissioned and
declared.

From there, I was able to access it via the UI and click Commission
Node and the node turned on and successfully booted the commissioning
image. (It was failing before because DNS was never started, causing the
commissioning image to hang)

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1266840

Title:
  maas-dns failed to install completely on Trusty

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1266840/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1266840] [NEW] maas-dns failed to install completely on Trusty

2014-01-07 Thread Jeff Lane
Public bug reported:

Installed maas packages on a fresh trusty install like so:

$ sudo apt-get install maas maas-region-controller maas-cluster-
controller maas-dhcp maas-dns

Installation proceeded successfully until maas-dns.  maas-dns errored
out:

Setting up maas (1.4+bzr1789+dfsg-0ubuntu1) ...
Processing triggers for libc-bin ...
Errors were encountered while processing:
 maas-dns
E: Sub-process /usr/bin/dpkg returned an error code (1)

After apt-get exited, I re-ran the comand and this time the
configuration of maas-dns seems to have successfully completed and
exited, but there was a failure when trying to restart bind9:

bladernr@critical-maas:~$ sudo apt-get install maas maas-region-controller 
maas-cluster-controller maas-dns maas-dhcp
[sudo] password for bladernr: 
Reading package lists... Done
Building dependency tree   
Reading state information... Done
maas is already the newest version.
maas-cluster-controller is already the newest version.
maas-dhcp is already the newest version.
maas-dns is already the newest version.
maas-region-controller is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Setting up maas-dns (1.4+bzr1789+dfsg-0ubuntu1) ...
 * Stopping domain name service... bind9
waiting for pid 22203 to die
 [ OK ]
 * Starting domain name service... bind9 [fail] 
invoke-rc.d: initscript bind9, action restart failed.

Looking in the apt term.log, I noticed this traceback the first time I tried 
installing maas-dns:
Setting up maas-dns (1.4+bzr1789+dfsg-0ubuntu1) ...
Traceback (most recent call last):
  File /usr/bin/django-admin, line 5, in module
management.execute_from_command_line()
  File /usr/lib/python2.7/dist-packages/django/core/management/__init__.py, 
line 399, in execute_from_command_line
utility.execute()
  File /usr/lib/python2.7/dist-packages/django/core/management/__init__.py, 
line 392, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
  File /usr/lib/python2.7/dist-packages/django/core/management/base.py, line 
242, in run_from_argv
self.execute(*args, **options.__dict__)
  File /usr/lib/python2.7/dist-packages/django/core/management/base.py, line 
285, in execute
output = self.handle(*args, **options)
  File 
/usr/lib/python2.7/dist-packages/maasserver/management/commands/set_up_dns.py,
 line 54, in handle
upstream_dns = Config.objects.get_config(upstream_dns)
  File /usr/lib/python2.7/dist-packages/maasserver/models/config.py, line 93, 
in get_config
return self.get(name=name).value
  File /usr/lib/python2.7/dist-packages/django/db/models/manager.py, line 
151, in get
return self.get_queryset().get(*args, **kwargs)
  File /usr/lib/python2.7/dist-packages/django/db/models/query.py, line 301, 
in get
num = len(clone)
  File /usr/lib/python2.7/dist-packages/django/db/models/query.py, line 77, 
in __len__
self._fetch_all()
  File /usr/lib/python2.7/dist-packages/django/db/models/query.py, line 854, 
in _fetch_all
self._result_cache = list(self.iterator())
  File /usr/lib/python2.7/dist-packages/django/db/models/query.py, line 220, 
in iterator
for row in compiler.results_iter():
  File /usr/lib/python2.7/dist-packages/django/db/models/sql/compiler.py, 
line 710, in results_iter
for rows in self.execute_sql(MULTI):
  File /usr/lib/python2.7/dist-packages/django/db/models/sql/compiler.py, 
line 780, in execute_sql
cursor = self.connection.cursor()
  File /usr/lib/python2.7/dist-packages/django/db/backends/__init__.py, line 
159, in cursor
cursor = util.CursorWrapper(self._cursor(), self)
  File /usr/lib/python2.7/dist-packages/django/db/backends/__init__.py, line 
129, in _cursor
self.ensure_connection()
  File /usr/lib/python2.7/dist-packages/django/db/backends/__init__.py, line 
124, in ensure_connection
self.connect()
  File /usr/lib/python2.7/dist-packages/django/db/utils.py, line 99, in 
__exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
  File /usr/lib/python2.7/dist-packages/django/db/backends/__init__.py, line 
124, in ensure_connection
self.connect()
  File /usr/lib/python2.7/dist-packages/django/db/backends/__init__.py, line 
112, in connect
self.connection = self.get_new_connection(conn_params)
  File 
/usr/lib/python2.7/dist-packages/django/db/backends/postgresql_psycopg2/base.py,
 line 116, in get_new_connection
return Database.connect(**conn_params)
  File /usr/lib/python2.7/dist-packages/psycopg2/__init__.py, line 179, in 
connect
connection_factory=connection_factory, async=async)
django.db.utils.OperationalError: FATAL:  password authentication failed for 
user maas
FATAL:  password authentication failed for user maas

dpkg: 

[Bug 1266840] Re: maas-dns failed to install completely on Trusty

2014-01-07 Thread Jeff Lane
Looked into syslog when manually restarting bind9 and it seems to hang on the 
maas zone file:
Jan  7 11:28:16 critical-maas named[29464]: starting BIND 
9.9.3-rpz2+rl.13214.22-P2-Ubuntu-1:9.9.3.dfsg.P2-4ubuntu2 -u bind
Jan  7 11:28:16 critical-maas named[29464]: built with '--prefix=/usr' 
'--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc/bind' 
'--localstatedir=/var' '--enable-threads' '--enable-largefile' '--with-libtool' 
'--enable-shared' '--enable-static' '--with-openssl=/usr' '--with-gssapi=/usr' 
'--with-gnu-ld' '--with-geoip=/usr' '--with-atf=no' '--enable-ipv6' 
'--enable-filter-' 'CFLAGS=-fno-strict-aliasing -DDIG_SIGCHASE -O2'
Jan  7 11:28:16 critical-maas named[29464]: 

Jan  7 11:28:16 critical-maas named[29464]: BIND 9 is maintained by Internet 
Systems Consortium,
Jan  7 11:28:16 critical-maas named[29464]: Inc. (ISC), a non-profit 501(c)(3) 
public-benefit 
Jan  7 11:28:16 critical-maas named[29464]: corporation.  Support and training 
for BIND 9 are 
Jan  7 11:28:16 critical-maas named[29464]: available at 
https://www.isc.org/support
Jan  7 11:28:16 critical-maas named[29464]: 

Jan  7 11:28:16 critical-maas named[29464]: adjusted limit on open files from 
4096 to 1048576
Jan  7 11:28:16 critical-maas named[29464]: found 4 CPUs, using 4 worker threads
Jan  7 11:28:16 critical-maas named[29464]: using 4 UDP listeners per interface
Jan  7 11:28:16 critical-maas named[29464]: using up to 4096 sockets
Jan  7 11:28:16 critical-maas named[29464]: loading configuration from 
'/etc/bind/named.conf'
Jan  7 11:28:16 critical-maas named[29464]: /etc/bind/named.conf.local:9: open: 
/etc/bind/maas/named.conf.maas: file not found
Jan  7 11:28:16 critical-maas named[29464]: loading configuration: file not 
found
Jan  7 11:28:16 critical-maas named[29464]: exiting (due to fatal error)

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1266840

Title:
  maas-dns failed to install completely on Trusty

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1266840/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1266893] [NEW] unable to complete getting the ephemeral images

2014-01-07 Thread Jeff Lane
Public bug reported:

My setup:
Trusty on an IBM Thinkpad x201.
Onboard Gigabit is static on 10.0.0.0 (The private MAAS lan)
Internet connectivity is via an 802.11n WiFi dongle
My internet connection is a 10Mbit ADSL line

I have installed and configured maas.  The next step, per the
instructions here:

maas.ubuntu.com/docs/instal.html#import-the-boot-images

is this:

$ maas-cli maas nde-groups import-boot-images

While doing this, I observed that it first called maas-import-pxe-files
which ran to completion pulling all the PXE files and putting them in
/var/lib/maas/tftp/*

Next, it calls maas-import-ephemerals

This ran and did NOTHING.  It just sat there, no network traffic in or
out, no disk activity, no data written to /var/lib/maas/ephemeral.  I
left it sitting for over an hour and it never actually started
downloading any images .

I finally killed off the process and ran maas-import-ephemerals
manually.  This time, it did begin downloading images, converting them
and copying them to /var/lib/maas/ephemerals.  But then it just stopped
as though it had lost the connection th wherever it's downloading from,
or something.  It never exited, it just ... paused and never restarted.
I let THIS sit for an hour and noticed that there was absolutely NO
further related network activity, disk activity or aything.

So I finally killed that process off as well.

Next, I tried breaking it down into smaller chunks like so:

$ sudo maas-import-ephemerals release=RELEASE

Doing it this way, I was able to fully download Saucy, Raring, Quantal
and Precise.  Currently, trying with trusty does nothing (it doesn't
seem to do anything at all.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: maas 1.4+bzr1789+dfsg-0ubuntu1
ProcVersionSignature: Ubuntu 3.12.0-7.15-generic 3.12.4
Uname: Linux 3.12.0-7-generic x86_64
ApportVersion: 2.12.7-0ubuntu3
Architecture: amd64
CurrentDesktop: Unity
Date: Tue Jan  7 13:08:02 2014
InstallationDate: Installed on 2014-01-07 (0 days ago)
InstallationMedia: Ubuntu 14.04 LTS Trusty Tahr - Alpha amd64 (20140106)
PackageArchitecture: all
SourcePackage: maas
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: maas (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug trusty

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1266893

Title:
  unable to complete getting the ephemeral images

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1266893/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1210307] Re: package tgt 1:1.0.37-0ubuntu1 failed to install/upgrade: subprocess new pre-removal script returned error exit status 1

2013-09-05 Thread Jeff Lane
* Stopping target framework daemon tgtd   ESC[80G 
^MESC[74G[ESC[31mfailESC[39;49m]
invoke-rc.d: initscript tgt, action stop failed.
dpkg: warning: subprocess old pre-removal script returned error exit status 1
dpkg: trying script from the new package instead ...
 * Stopping target framework daemon tgtd   ESC[80G 
^MESC[74G[ESC[31mfailESC[39;49m]
invoke-rc.d: initscript tgt, action stop failed.
dpkg: error processing 
/var/cache/apt/archives/tgt_1%3a1.0.38-0ubuntu1_amd64.deb (--unpack):
 subprocess new pre-removal script returned error exit status 1

There appears to be no log for tgt... the only references I could find
are the above in apt/term.log

and the following from syslog:
Sep  5 10:55:56 klaatu tgtd: semkey 0x610ff449
Sep  5 10:55:56 klaatu tgtd: tgtd daemon started, pid:14792
Sep  5 10:55:56 klaatu tgtd: tgtd logger started, pid:14793 debug:0
Sep  5 10:55:56 klaatu kernel: [ 7247.887727] tgtd (14792): /proc/14792/oom_adj 
is deprecated, please use /proc/14792/oom_score_adj instead.
Sep  5 10:55:57 klaatu tgtd: iser_ib_init(3349) Failed to initialize RDMA; load 
kernel modules?
Sep  5 10:55:57 klaatu tgtd: work_timer_start(150) use signal based scheduler
Sep  5 10:55:57 klaatu tgtd: bs_init(316) use signalfd notification


** Changed in: tgt (Ubuntu)
   Status: Incomplete = New

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to tgt in Ubuntu.
https://bugs.launchpad.net/bugs/1210307

Title:
  package tgt 1:1.0.37-0ubuntu1 failed to install/upgrade: subprocess
  new pre-removal script returned error exit status 1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tgt/+bug/1210307/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1210307] [NEW] package tgt 1:1.0.37-0ubuntu1 failed to install/upgrade: subprocess new pre-removal script returned error exit status 1

2013-08-08 Thread Jeff Lane
Public bug reported:

Did a general dist-upgrade on saucy.  I have TGT installed for some work
with devstack.  For some reason, tgt failed to upgrade and that caused
apt to throw an error.

ProblemType: Package
DistroRelease: Ubuntu 13.10
Package: tgt 1:1.0.37-0ubuntu1
ProcVersionSignature: Ubuntu 3.10.0-6.17-generic 3.10.3
Uname: Linux 3.10.0-6-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.12-0ubuntu3
Architecture: amd64
Date: Thu Aug  8 08:49:58 2013
DuplicateSignature: package:tgt:1:1.0.37-0ubuntu1:subprocess new pre-removal 
script returned error exit status 1
ErrorMessage: subprocess new pre-removal script returned error exit status 1
InstallationDate: Installed on 2012-03-15 (511 days ago)
InstallationMedia: Ubuntu 12.04 LTS Precise Pangolin - Alpha amd64 (20120307)
MarkForUpload: True
SourcePackage: tgt
Title: package tgt 1:1.0.37-0ubuntu1 failed to install/upgrade: subprocess new 
pre-removal script returned error exit status 1
UpgradeStatus: Upgraded to saucy on 2013-06-22 (47 days ago)
modified.conffile..etc.init.tgt.conf: [deleted]
mtime.conffile..etc.tgt.targets.conf: 2013-05-10T14:34:21.654054

** Affects: tgt (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-package saucy

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to tgt in Ubuntu.
https://bugs.launchpad.net/bugs/1210307

Title:
  package tgt 1:1.0.37-0ubuntu1 failed to install/upgrade: subprocess
  new pre-removal script returned error exit status 1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tgt/+bug/1210307/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 828437] Re: chkrootkit cron job went nuts, spawned 14 instances and consumed nearly 90% of my ram

2013-01-30 Thread Jeff Lane
Over a year old, never addressed. Closing.
 I think it eventually went away  so probably fixed.

** Changed in: chkrootkit (Ubuntu)
   Status: New = Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to chkrootkit in Ubuntu.
https://bugs.launchpad.net/bugs/828437

Title:
  chkrootkit cron job went nuts, spawned 14 instances and consumed
  nearly 90% of my ram

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/chkrootkit/+bug/828437/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 565578] Re: chkutmp crashed with SIGSEGV in _Unwind_Backtrace()

2013-01-30 Thread Jeff Lane
Old bug

** Changed in: chkrootkit (Ubuntu)
   Status: Expired = Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to chkrootkit in Ubuntu.
https://bugs.launchpad.net/bugs/565578

Title:
  chkutmp crashed with SIGSEGV in _Unwind_Backtrace()

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/chkrootkit/+bug/565578/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 641657] Re: SSH connections freeze after a period of time

2013-01-30 Thread Jeff Lane
Maverick is dead. Closing bug properly.

** Changed in: openssh (Ubuntu)
   Status: Expired = Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/641657

Title:
  SSH connections freeze after a period of time

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/641657/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 828437] Re: chkrootkit cron job went nuts, spawned 14 instances and consumed nearly 90% of my ram

2011-08-22 Thread Jeff Lane
forgot to reset to new when I added my update.

** Changed in: chkrootkit (Ubuntu)
   Status: Incomplete = New

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to chkrootkit in Ubuntu.
https://bugs.launchpad.net/bugs/828437

Title:
  chkrootkit cron job went nuts, spawned 14 instances and consumed
  nearly 90% of my ram

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/chkrootkit/+bug/828437/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 828437] Re: chkrootkit cron job went nuts, spawned 14 instances and consumed nearly 90% of my ram

2011-08-18 Thread Jeff Lane
Serge: at the moment, no.  I can't manually reproduce it. However, I
left the machine sitting over night and came back this morning to find
that it was stuck yet again, this time, the egrep process was using
7.1GB of 8GB, but PS only showed 2 instances running...

I'm currently running tiger manually to see if it's tiger itself, or
something related to running via CRON.  after the manual run, I'll try
running the commands from the cron scripts manually and see if that
recreates the issue.

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to chkrootkit in Ubuntu.
https://bugs.launchpad.net/bugs/828437

Title:
  chkrootkit cron job went nuts, spawned 14 instances and consumed
  nearly 90% of my ram

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/chkrootkit/+bug/828437/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 828437] [NEW] chkrootkit cron job went nuts, spawned 14 instances and consumed nearly 90% of my ram

2011-08-17 Thread Jeff Lane
Public bug reported:

Walked away for a while and returned to find my system almost unusable.
Something was causing the DISK I/O to go through the roof, the system
constantly waiting, making it, as I said, almost unusable.

On some investigation, top indicated that egrep was consuming 6.7 GB of
actual memory (of 8 GB total system RAM).  Looking at the output of 'ps
axf' showed 14 instances of chkrootkit and egrep's

My system being DOS'd locally by chkrootkit... the irony is not lost on
me.

No idea why this happened, or even where to start wtih it, but I thought
I'd at least open a bug and report what I could... but I had to reboot
the system the hard way before I could even do that.

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: chkrootkit 0.49-4ubuntu1
ProcVersionSignature: Ubuntu 2.6.38-10.46-generic 2.6.38.7
Uname: Linux 2.6.38-10-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
Date: Wed Aug 17 20:34:52 2011
InstallationMedia: Ubuntu 9.10 Karmic Koala - Release amd64 (20091027)
ProcEnviron:
 LANGUAGE=en_US:en
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: chkrootkit
UpgradeStatus: Upgraded to natty on 2011-06-03 (75 days ago)

** Affects: chkrootkit (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug natty running-unity

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to chkrootkit in Ubuntu.
https://bugs.launchpad.net/bugs/828437

Title:
  chkrootkit cron job went nuts, spawned 14 instances and consumed
  nearly 90% of my ram

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/chkrootkit/+bug/828437/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 828437] Re: chkrootkit cron job went nuts, spawned 14 instances and consumed nearly 90% of my ram

2011-08-17 Thread Jeff Lane
-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to chkrootkit in Ubuntu.
https://bugs.launchpad.net/bugs/828437

Title:
  chkrootkit cron job went nuts, spawned 14 instances and consumed
  nearly 90% of my ram

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/chkrootkit/+bug/828437/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 828437] Re: chkrootkit cron job went nuts, spawned 14 instances and consumed nearly 90% of my ram

2011-08-17 Thread Jeff Lane
This is a batch mode output from top, showing the egrep process
consuming 6.7GB of my RAM...

** Attachment added: top.log
   
https://bugs.launchpad.net/ubuntu/+source/chkrootkit/+bug/828437/+attachment/2287476/+files/top.log

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to chkrootkit in Ubuntu.
https://bugs.launchpad.net/bugs/828437

Title:
  chkrootkit cron job went nuts, spawned 14 instances and consumed
  nearly 90% of my ram

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/chkrootkit/+bug/828437/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 828437] Re: chkrootkit cron job went nuts, spawned 14 instances and consumed nearly 90% of my ram

2011-08-17 Thread Jeff Lane
this is a capture of ps axf before rebooting the system to make it
usable again.  Notice the 14 instances of egrep spawned by chkrootkit.


** Attachment added: ps-axf.log
   
https://bugs.launchpad.net/ubuntu/+source/chkrootkit/+bug/828437/+attachment/2287477/+files/ps-axf.log

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to chkrootkit in Ubuntu.
https://bugs.launchpad.net/bugs/828437

Title:
  chkrootkit cron job went nuts, spawned 14 instances and consumed
  nearly 90% of my ram

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/chkrootkit/+bug/828437/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 828437] Re: chkrootkit cron job went nuts, spawned 14 instances and consumed nearly 90% of my ram

2011-08-17 Thread Jeff Lane
Also, this might actually be an issue created by tiger, rather than
chkrootkit itself...

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to chkrootkit in Ubuntu.
https://bugs.launchpad.net/bugs/828437

Title:
  chkrootkit cron job went nuts, spawned 14 instances and consumed
  nearly 90% of my ram

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/chkrootkit/+bug/828437/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Blueprint server-o-load-testing] Server Load Testing Suite

2011-06-06 Thread Jeff Lane
Blueprint changed by Jeff Lane:

Whiteboard changed:
  Work Items:
- [bladernr] Jeff to list the testing team info so interested parties can sign 
up and participate in making this happen: DONE
- Create a list of the tests to be run (a small number of useful tests to 
start, we can expand afterwards).: TODO
- Documentation of test cases and configs and other useful information (wiki?, 
testcases.qa.ubuntu.com?): TODO
- Package a consistently runnable test suite: TODO
+ [bladernr] Jeff to list the testing team info so interested parties can sign 
up and participate in making this happen: DONE
+ [hardware-cert team] Create a list of the tests to be run (a small number of 
useful tests to start, we can expand afterwards).: TODO
+ [hardware-cert team] Documentation of test cases and configs and other useful 
information (wiki?, testcases.qa.ubuntu.com?): TODO
+ [hardware-cert team] Package a consistently runnable test suite: TODO
  
  Previous discussions:
  
https://blueprints.launchpad.net/ubuntu/+spec/packageselection-arm-server-optimized-lamp-stack
  
https://wiki.ubuntu.com/UDSProceedings/N/PackageSelectionAndSystemDefaults#Arm%20Server%20Optimized%20Lamp%20Stack
  
  Notes from this session:
  http://summit.ubuntu.com/uds-o/meeting/server-o-load-testing/
  
  Q: Can you please try to address IPMI (Server management) as well
  A: To what extent?  There is already an IPMI test that performs basic 
function testing (e.g. connect to the BMC, pull SEL events and system info to 
ensure that the IPMI bits are working).
  
  Definition of Done:
  1: Defined list of specific hardware subsystems on servers that are to be 
tested
  2: Defined list of specific common server applications that are to be tested
  3: Scope infrastructure changes as may be needed (new hardware, etc)
  4: Defined list of tests that will verify server stability and functionality
  5: Defined limits on what is acceptable load minimums and maximums for testing
  6: Defined list of which tests will be hardware certification tests and which 
will be QA style tests
  7: Responsibilities for each set of tests assigned to the appropriate teams
  8: Tests written if they do not currently exist, tested for usability and 
implemented in Checkbox
  9: Separate whitelists defined in checkbox for server certification and 
server QA
  10: New infrastructure in place and operational if necessary
  11: Servers tested using full server certification and server QA whitelists
  12: 11.10 is thoroughly hammered using our new combined Super Monkey Powers
  13: 12.04 is the best Server LTS EVER!

-- 
Server Load Testing Suite
https://blueprints.launchpad.net/ubuntu/+spec/server-o-load-testing

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 661591] Re: checkbox threw an error during a network test

2011-03-11 Thread Jeff Lane
** Changed in: checkbox-certification
   Status: Fix Committed = Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ntp in ubuntu.
https://bugs.launchpad.net/bugs/661591

Title:
  checkbox threw an error during a network test

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 110992] Re: ipmi modules need to manually inserted and device created

2011-03-08 Thread Jeff Lane
Why is this still even an issue?

Verified that on the latest Lucid SRU, ipmi_si and ipmi_msghandler load
at boot but ipmi_devintf does not.

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is a direct subscriber.
https://bugs.launchpad.net/bugs/110992

Title:
  ipmi modules need to manually inserted and device created

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 110992] Re: ipmi modules need to manually inserted and device created

2011-03-08 Thread Jeff Lane
Ok... so further investigation:

Fresh Natty install on an IBM server with BMC using the latest ISOs as
of 8 March.

Looking in /lib/modules/2.6.38-5-generic/kernel/drivers/char/ipmi/ shows that 
the drivers are present.
No IPMI packages are installed:

First I install ipmitool:


ubuntu@ubuntu:~$ sudo apt-get install ipmitool
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Suggested packages:
  openipmi
The following NEW packages will be installed:
  ipmitool
0 upgraded, 1 newly installed, 0 to remove and 13 not upgraded.
Need to get 418 kB of archives.
After this operation, 1,118 kB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu/ natty/universe ipmitool amd64 
1.8.11-2ubuntu3 [418 kB]
Fetched 418 kB in 0s (431 kB/s)   
ySelecting previously deselected package ipmitool.
(Reading database ... 30797 files and directories currently installed.)
Unpacking ipmitool (from .../ipmitool_1.8.11-2ubuntu3_amd64.deb) ...
Processing triggers for ureadahead ...
ureadahead will be reprofiled on next reboot
Processing triggers for man-db ...
Setting up ipmitool (1.8.11-2ubuntu3) ...
ipmievd: using pidfile /var/run/ipmievd.pid0
Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0: No such 
file or directory
Unable to open interface
invoke-rc.d: initscript ipmievd, action start failed.
Unable to start ipmievd during installation.  Trying to disable.

Also note that installing ipmitool does not install any other packages
at all.

These errors happened because /dev/ipmi0 is not created... that requires
ipmi_devmntf to be loaded.  One would think that since I just installed
ipmitool, which includes ipmievd to pass BMC messages on to syslog, that
as soon as I reboot, the modules would be loaded, /dev/ipmi0 would be
created and everthing would be copacetic.  So after installing ipmitool
and verifying that ipmievd was not running, /dev/ipmi0 was not there,
and the modules were not loaded, I rebooted the server to see what would
happen.

ipmi modules are NOT loaded, ipmievd is not started, and /dev/ipmi0 is
not created, thus, nothing.

Now I install the openipmi package (which is NOT pulled in by installing
ipmitool):


ubuntu@ubuntu:~$ sudo apt-get install openipmi
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following extra packages will be installed:
  libopenipmi0 libperl5.10 libsensors4 libsnmp-base libsnmp15
Suggested packages:
  lm-sensors snmp-mibs-downloader
The following NEW packages will be installed:
  libopenipmi0 libperl5.10 libsensors4 libsnmp-base libsnmp15 openipmi
0 upgraded, 6 newly installed, 0 to remove and 13 not upgraded.
Need to get 2,288 kB of archives.
After this operation, 6,595 kB of additional disk space will be used.
Do you want to continue [Y/n]? y
Get:1 
http://10.189.84.1/enablement/cdimage.ubuntu.com/ubuntu-server/daily/current/natty-server-amd64/
 natty/main libopenipmi0 amd64 2.0.18-0ubuntu3 [559 kB]
Get:2 
http://10.189.84.1/enablement/cdimage.ubuntu.com/ubuntu-server/daily/current/natty-server-amd64/
 natty/main libperl5.10 amd64 5.10.1-17ubuntu3 [1,200 B]
Get:3 
http://10.189.84.1/enablement/cdimage.ubuntu.com/ubuntu-server/daily/current/natty-server-amd64/
 natty/main libsensors4 amd64 1:3.2.0-1 [32.8 kB]
Get:4 
http://10.189.84.1/enablement/cdimage.ubuntu.com/ubuntu-server/daily/current/natty-server-amd64/
 natty/main libsnmp-base all 5.4.3~dfsg-2ubuntu1 [214 kB]
Get:5 
http://10.189.84.1/enablement/cdimage.ubuntu.com/ubuntu-server/daily/current/natty-server-amd64/
 natty/main libsnmp15 amd64 5.4.3~dfsg-2ubuntu1 [1,336 kB]
Get:6 
http://10.189.84.1/enablement/cdimage.ubuntu.com/ubuntu-server/daily/current/natty-server-amd64/
 natty/main openipmi amd64 2.0.18-0ubuntu3 [146 kB]
Fetched 2,288 kB in 0s (26.5 MB/s)
Selecting previously deselected package libopenipmi0.
(Reading database ... 30810 files and directories currently installed.)
Unpacking libopenipmi0 (from .../libopenipmi0_2.0.18-0ubuntu3_amd64.deb) ...
Selecting previously deselected package libperl5.10.
Unpacking libperl5.10 (from .../libperl5.10_5.10.1-17ubuntu3_amd64.deb) ...
Selecting previously deselected package libsensors4.
Unpacking libsensors4 (from .../libsensors4_1%3a3.2.0-1_amd64.deb) ...
Selecting previously deselected package libsnmp-base.
Unpacking libsnmp-base (from .../libsnmp-base_5.4.3~dfsg-2ubuntu1_all.deb) ...
Selecting previously deselected package libsnmp15.
Unpacking libsnmp15 (from .../libsnmp15_5.4.3~dfsg-2ubuntu1_amd64.deb) ...
Selecting previously deselected package openipmi.
Unpacking openipmi (from .../openipmi_2.0.18-0ubuntu3_amd64.deb) ...
Processing triggers for man-db ...
Processing triggers for ureadahead ...
ureadahead will be reprofiled on next reboot
Setting up libopenipmi0 (2.0.18-0ubuntu3) ...
Setting up libperl5.10 (5.10.1-17ubuntu3) ...
Setting up libsensors4 (1:3.2.0-1) ...
Setting up libsnmp-base (5.4.3~dfsg-2ubuntu1) ...
Setting up libsnmp15 

[Bug 110992] Re: ipmi modules need to manually inserted and device created

2011-03-08 Thread Jeff Lane
Also, by pulling in openipmi I mean that perhaps the control file for
the ipmitool package could change from suggesting openipmi to
recommending openipmi

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is a direct subscriber.
https://bugs.launchpad.net/bugs/110992

Title:
  ipmi modules need to manually inserted and device created

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 661591] Re: checkbox threw an error during a network test

2010-10-16 Thread Jeff Lane
** Changed in: ntp (Ubuntu)
   Status: New = Incomplete

** Changed in: ntp (Ubuntu)
   Status: Incomplete = Opinion

** Changed in: ntp (Ubuntu)
   Status: Opinion = Invalid

-- 
checkbox threw an error during a network test
https://bugs.launchpad.net/bugs/661591
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ntp in ubuntu.

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 661591] Re: checkbox threw an error during a network test

2010-10-16 Thread Jeff Lane
** Changed in: checkbox-certification
   Importance: Undecided = High

-- 
checkbox threw an error during a network test
https://bugs.launchpad.net/bugs/661591
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ntp in ubuntu.

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 661591] Re: checkbox threw an error during a network test

2010-10-16 Thread Jeff Lane
Job description was incorrectly calling network_ntp_test script.  Fixed
that.

** Changed in: checkbox-certification
   Status: New = Fix Committed

-- 
checkbox threw an error during a network test
https://bugs.launchpad.net/bugs/661591
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ntp in ubuntu.

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 661591] [NEW] checkbox threw an error during a network test

2010-10-15 Thread Jeff Lane
Public bug reported:

Binary package hint: ntp

Not sure which test... it appears to be the ntp test that caused
checkbox to start a bug report.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: ntpdate 1:4.2.4p8+dfsg-1ubuntu6
ProcVersionSignature: Ubuntu 2.6.35-22.33-generic 2.6.35.4
Uname: Linux 2.6.35-22-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
CheckboxCommand: network_ntp_test --server $NTP_SERVER
CheckboxData:
 Usage: network_ntp_test [OPTIONS]
 
 network_ntp_test: error: --server option requires an argument
CheckboxDescription: Test to see if we can sync local clock to an NTP server
CheckboxTest: network_ntp_test
Date: Sat Oct 16 01:09:16 2010
InstallationMedia: Ubuntu 10.10 Maverick Meerkat - Release amd64 (20101007)
ProcEnviron:
 SHELL=/bin/bash
 LANG=en_US.UTF-8
SourcePackage: ntp

** Affects: checkbox-certification
 Importance: Undecided
 Assignee: Jeff Lane (bladernr)
 Status: New

** Affects: ntp (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug checkbox-bug maverick

-- 
checkbox threw an error during a network test
https://bugs.launchpad.net/bugs/661591
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ntp in ubuntu.

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 661591] Re: checkbox threw an error during a network test

2010-10-15 Thread Jeff Lane

** Also affects: checkbox-certification
   Importance: Undecided
   Status: New

** Changed in: checkbox-certification
 Assignee: (unassigned) = Jeff Lane (bladernr)

-- 
checkbox threw an error during a network test
https://bugs.launchpad.net/bugs/661591
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ntp in ubuntu.

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 641657] Re: SSH connections freeze after a period of time

2010-09-19 Thread Jeff Lane
Hi Steve,

Actually, I'm seeing it on any remote SSH connection (either to a
Canonical DC or to my own shared server).

I'm in Taipei at the moment so I'll try again here just to see if
there's something wonky on my end (router, or switch maybe) causing the
SSH connection do hang...

As for the rest, I haven't done an strace on it, nor a -vv... but I'll
keep that in mind too.  It doesn't respond, that I know of to the escape
char, but to be perfectly honest, I'm not sure I tried '~' anyway... I
keep trying telnet chars by habit... so another thing to thing to try.

I'm going to leave this as incomplete for the moment and I'll try to get
an strace from a failing condition and try some other stuff (like from
this different location) and see what happens.

-- 
SSH connections freeze after a period of time
https://bugs.launchpad.net/bugs/641657
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openssh in ubuntu.

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 641657] [NEW] SSH connections freeze after a period of time

2010-09-17 Thread Jeff Lane
Public bug reported:

Maverick with latest updates as of 17 Sept 2010

I've noticed since upgrading from 10.04.1 to Maverick that SSH sessions
now seem to freeze after a period of time.

I am able to ssh to a remote server (I'm sshing to my personal server
and to some work servers in one of the DCs) and do things.

However, after letting the connection sit idle for a bit it just freezes
and I have to kill the terminal it's in, or kill the ssh process that's
running.

I never saw this issue until upgrading to Maverick.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: openssh-client 1:5.5p1-4ubuntu4
ProcVersionSignature: Ubuntu 2.6.35-20.29-generic 2.6.35.4
Uname: Linux 2.6.35-20-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
Date: Fri Sep 17 17:59:42 2010
InstallationMedia: Ubuntu 9.10 Karmic Koala - Release amd64 (20091027)
ProcEnviron:
 LANG=en_US.utf8
 SHELL=/bin/bash
SourcePackage: openssh

** Affects: openssh (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug maverick

-- 
SSH connections freeze after a period of time
https://bugs.launchpad.net/bugs/641657
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openssh in ubuntu.

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 641657] Re: SSH connections freeze after a period of time

2010-09-17 Thread Jeff Lane

** Attachment added: Dependencies.txt
   
https://bugs.launchpad.net/bugs/641657/+attachment/1599958/+files/Dependencies.txt

-- 
SSH connections freeze after a period of time
https://bugs.launchpad.net/bugs/641657
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openssh in ubuntu.

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs