Re: Ubuntu Server seeded package review

[Dustin Kirkland]

On Tue, Dec 3, 2013 at 4:50 PM, Barry Warsaw  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Dec 03, 2013, at 04:33 PM, James Page wrote:
>
>>As part of tidying for the next LTS release, the Server Team are
>>proposing a review of server released seeded packages that are
>>currently in Ubuntu main (proposed changes tracked in [0] for now).
>
> Continuing to demote Python 2, we want to get rid of it on server[*] if at all
> possible.  For example, I've identified byobu, landscape-common, and vim as
> three packages with `Task: server` pulling in Python 2.7.
>
> For byobu, we have LP: #1253458, currently waiting on some feedback from
> Dustin.

This is incurring a bit of work for me upstream, in trying to continue
producing a Byobu orig tarball that runs everywhere (back to Ubuntu
12.04, weird UNIXes, weird Linuxes)...

But you have my commitment that it will be fixed for Ubuntu 14.04.  Thanks ;-)

> For vim, we have http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729924
> currently waiting on feedback from Debian Vim maintainers.  I'm not a Vim
> user, but if you want to help test this, a package is available in my PPA:
>
> https://launchpad.net/~barry/+archive/experimental
>
> Based on your feedback, I'd be willing to temporarily get ahead of Debian 
> here.
>
> landscape-client may be trickier because that gets us into some Twisted
> packages, which aren't yet packaged for Python 3.
>
> See also (and add anything missing!):
>
> https://blueprints.launchpad.net/ubuntu/+spec/core-1311-python3-roadmap
> http://tinyurl.com/mmj4y6a
>
>>http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.trusty/view/head:/server-ship
>
>>Description: Server ISO image
>>
>>nut, nut-cgi, nut-snmp (move to supported-misc-servers)
>>likewise-open (largely unmaintained in distro -
>>https://help.ubuntu.com/community/LikewiseOpen)
>>powernap, powernap-server (still revelvant?)
>
> Looks like powernap still depends on Python 2.
>
>>quagga (maybe move to supported-misc-servers)
>>backuppc
>>python-beautifulsoup
>
> Whatever is pulling this one in should be ported to python3-bs4, or at least
> python-bs4 since afaict beautifulsoup 3 is no longer being actively maintained
> upstream (critical bug fixes only according to them).
>
>>python-genshi (will be pulled into main via supported-misc-servers ...
>
> Upstream 0.7 supports Python 3, but not yet Debian - BTS #731280.
>
>>python-pecan)
>
> Upstream 0.4.2 supports Python 3, but not yet Debian - BTS #731283.
>
> Cheers,
> - -Barry
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.15 (GNU/Linux)
>
> iQIcBAEBCAAGBQJSnmBKAAoJEBJutWOnSwa/6vsP/jNdnhx9xIM7HiNvgaL0QIr0
> DTuZwxL87E086hdDY0X8fqTf/vT+Xo+zecuHwedePIOL8BZlA/mWX8Bsge7nQc3g
> 1jInf6rBR6qNMgEos1gh/5xTJgvq+WS7zLLrPwabejWmOlyT7R13mPEEuJ5ozBfC
> G8QcH5Hl61B84SbTd2Pfxjfr+ae6gxsfuqhQcYJ4JuIQ5EIvSV0txvG2tRJuUaCG
> AXGg3kiX4IbjeKIMIr4MO9YRlNhgJTp1QR8j4wsZU8yH3xyjukOeBd5jlD+zItT8
> ZlCVdiXZaPR3qsBNIZTszVQ8W00h6515BOhdW/RydmyzA/bf15usaJPImlJjpQ0d
> AWEpsO3a9RlKzJBmfiwNYAkUPBd+xRNT0DVDRF+XhVrUJLhee/U3VUl6luzu2I1V
> rYC0XU8TneEp92D0XNHM9IyNft0/UyfYQbioTBfb2NBnPRoa6pR25JsPMpod4fBW
> KBGvAcSg3Xkir7yghCQLNKIE5K6wb3gLufOXTjqnMSjajOk4NnRfI3hBHoiXMkh+
> 0fmkwpWHUeYbF7Hol+DYC297Nd/AbYxBfaE2FnC0ElE9Y6tjs/o9krarRtEX1Ay0
> kIYDTRMUBSMRhjm5TGY7LPKeOdMZHXfUTf75vtKdSecHk9Gt4hOvqR2J1Wh7nj82
> Vf7zIIz9Rl37N2JU8Hwe
> =A7DV
> -END PGP SIGNATURE-
> --
> ubuntu-devel mailing list
> ubuntu-de...@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Ubuntu Server seeded package review

[Dustin Kirkland]

On Tue, Dec 3, 2013 at 10:33 AM, James Page  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi Folks
>
> As part of tidying for the next LTS release, the Server Team are
> proposing a review of server released seeded packages that are
> currently in Ubuntu main (proposed changes tracked in [0] for now).
>
> Here's the initial review of seeds, and some proposed moves and drops
> we are considering:
>
> Branch:
> https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.trusty
>
> http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.trusty/view/head:/server
>
> Description: Default server install
>
> whoopsie (ack'ed by ev)
> wireless-tools
> wpasupplicant
>
> http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.trusty/view/head:/server-ship
>
> Description: Server ISO image
>
> nut, nut-cgi, nut-snmp (move to supported-misc-servers)
> likewise-open (largely unmaintained in distro -
> https://help.ubuntu.com/community/LikewiseOpen)
> powernap, powernap-server (still revelvant?)

No objection from me (co-maintainer) to drop PowerNap from the ISO.
It's still easy to get post installation.

> quagga (maybe move to supported-misc-servers)
> backuppc
> python-beautifulsoup
> python-genshi (will be pulled into main via supported-misc-servers ...
> python-pecan)
> whoopsie (ack'ed by ev)
> mutt
>
> http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.trusty/view/head:/cloud-image
>
> Description: Default cloud-image install
>
> whoopsie (ack'ed by ev)
> tasksel (drops aptitude etc.)
> euca2ools (move to supported-misc-servers)
>
> Branch:
> https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.trusty
>
> http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.trusty/view/head:/supported-misc-servers
>
> Description: Other supported stuff which is not on the ISO
>
> No candidates identified
>
> And a few other packages that we'd like to not be part of the cloud
> images (which include the 'cloud-image' and 'server' seeds).  These
> are not explicitly listed in either of these seeds but are pulled in
> due to dependencies or Recommends.
>
> ppp
> usbutils
> os-prober
> aptitude
> memtest86
>
> ... and discuss!
>
> I'd like to land any changes early in 2014 prior to feature freeze.
>
> Cheers
>
> James
>
> [0] http://pad.ubuntu.com/server-seed-review
>
> - --
> James Page
> Ubuntu and Debian Developer
> james.p...@ubuntu.com
> jamesp...@debian.org
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.15 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJSngfVAAoJEL/srsug59jDDG4QAJbbX1aii7pw1mOVliFOjrHc
> uDunTZ3acW9dpCL2CdnkHc1TDnEMczko/7Rm8VhdNqENkUc7Z3V6NEaq7itgG/a2
> w6dyszKm8c8MWvnr6lTpor1Hjb+7qomRZdqbQyQZGPCxQyrLbDR62ggEqYztVf36
> glatqylywKRIYhSdTCjD7OteDi9Sur76JOdmAkng+BsjWTnxFQgjju19qpl3MDvm
> iOzmd2WQk0GAGQWmrU/8UrKwjglPD+qXJpRjpdSQ3N2iKZRzW3XRXoXMlybqalJC
> dkXnfaDSv8sJsFZXatEA6T/3zcpZaByRcdxpEq8aP+EMTov1F6kDtBrXLfWquQGU
> V9BRRbfQCA+xPci9lqpcaRha1boFCGTDbp8zOpPhWUoJQzbUS/x1aKjrSggbRj+v
> jvrpPxsDud2xOVEcl5rIpmjEkv1YLTh0AVJL1rMI/CvXXvA52dlMwy2qoxN+i4JW
> PHMWVH6M29lNfO37/n3uloznVlNde+qR1uuUkZyzd86piHOReTUejUS+Cw5DxtAl
> EJooyuT/6eKVx2gY/MvkAWAiOxVXaHl8NaGr/l7sIZTOgL4eYw4flI1Z87X2O7X5
> fUM9iHX31wU8+jIjEehjeOWWaPNJ1WNMS+L8T9SiqCjy+PHvHAajhWd1hUrLiKs8
> HYRLA2uA4Zlf2pOuA6CL
> =fbfY
> -END PGP SIGNATURE-
>
> --
> ubuntu-devel mailing list
> ubuntu-de...@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Distro-provided mechanism to clean up old kernels

[Dustin Kirkland]

On Thu, Feb 16, 2012 at 3:08 PM, Craig White  wrote:
> this was interesting but I found that I had to NOT use 'head -n -2' but 
> rather 'head -n 2'

You can do 'head -2' or 'head -n2', but not 'head -n -2'.  I assumed
it was a typo ;-)

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Distro-provided mechanism to clean up old kernels

[Dustin Kirkland]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Thu, Feb 16, 2012 at 2:31 PM, Kees Cook  wrote:
> On Thu, Feb 16, 2012 at 02:21:18PM -0500, Barry Warsaw wrote:
>> On Feb 16, 2012, at 10:11 AM, Dustin Kirkland wrote:
>> >I asked about this in IRC yesterday, and Colin Watson pointed me to
>> >the computer-janitor utility, which is intended to handle this.
>> >Seconds later, Barry Warsaw told me that computer-janitor should die
>> >:-)
>>
>> c-j needs attention, but I'm not particularly motivated to give it what it
>> needs.  There's basic housekeeping, such as that the code for c-j is 
>> sprinkled
>> between the update-manager and the computer-janitor packages, and even more
>> important problems such LP: #458872.  What's demotivating though is that in
>> all the discussions we've had about the tool, most people think it's just not
>> user-friendly enough given today's emphasis on software-center.
>
> FWIW, this is the highly advanced system I use for my auto-updated VMs. It
> keeps the latest 2 kernels:
>
> OLD=$(ls -tr /boot/vmlinuz-* | head -n -2 | cut -d- -f2- | \
>        awk '{print "linux-image-" $0}')
> if [ -n "$OLD" ]; then
>    apt-get -qy remove --purge $OLD
> fi
>
> Be warned, of course, that if you don't reboot often, you can end up
> removing the kernel you're running. :P

Yeah, something like this, perhaps with a uname -r check, to also
exclude the current kernel you're running, which apparently *is* known
to work.

Regarding computer-janitor and the dbus discussion -- I certainly like
the idea of computer-janitor in general, but I think I agree with
Barry that it feels much more like a desktop than a server solution.

I guess what I would like to see is to take perhaps Kees' script as a
starting point, improve upon that logic slightly, and ship it within
Ubuntu as a consistent, supported, recommended mechanism for vacuuming
out unneeded kernels.  Something like 'remove-old-kernels', perhaps
shipping in computer-janitor, or ideally more pervasive.  In order to
be useful, though, we'd need to make that script available to
installed systems via SRU.

Barry, would you be willing to accept a shell script along these
lines, into computer-janitor, if I cleaned it up and proposed a merge
and shepherded it through the SRU process?  Or, is there a better home
we can agree upon?

- --
:-Dustin

Dustin Kirkland
Ubuntu Core Developer

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCgAGBQJPPXZdAAoJEJXmQ3PxUpRpLaUP/0WaUkIv2keM+ajQ4WTaCIi5
2pLc3Y5Jeds2/TLqMBKxdlx6M/Hh1wuUaIxYBB3d/nELYKCXbeCxiADfaBraRiet
PbPxooNKti3sbVc/vrgpu8oC54E8vb5Jc8d4zPr0qDcnKNMzHGPbxA78z8MlR+TQ
vqAPcmZcvKF9jUESvrdkYd9pefaLsFludHSwLjt2Dw7+SPsyOrXRBLw8FConBzoV
CHZXiI+FyKaMANwsHVX/2O+RrcpsCgwahQpCEjBFghumR09xTI4ONRpfgqzBDSuN
SSdVTvVCC56ZJ15ufJGCaRVWY7ESTq8deuODnD5/4xIKyVetJtZigPenGLB6N81l
eRtM9brTQAgdLgJ/BDr6TxIibwmgEzJp/EEKDC3tHvd2I7ZJZJ5WqYoyFMdtJRnh
Rwsdt9iEbqIn2pv677rGMpQjldgrAIwBPu+EqgCIbCMTse0/s5oATxhP/953fBB5
S14J+PTSOQh4FwHuzjcyMMdtltQyvjAXRZwm989MvblGcABck0nNMH1VJqIDR7ke
ujI+5kYeQGDszeddFhy8qtyqAyPj8hpyzgnDzh+5kQdtftMv8Qvci8tuxAvqNjI2
473WDq2RcqKXFI/hMT63Z44dkxzsht8NXwI1ksR8643fT/owsSZiKzwdxUCgWyyD
7ETOc6yNLB/Gs7o2t7z9
=lFFF
-END PGP SIGNATURE-

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Distro-provided mechanism to clean up old kernels

[Dustin Kirkland]

I understand that I'm not the first to ask this question.  In fact, I
see at least 10 similar questions at AskUbuntu.com, and many more
duplicates:
 * http://askubuntu.com/search?q=remove+old+kernels

This week, I received a message from one of our commercial ISP/Cloud
Hosting Providers, saying:
>>> Unlike other Linux distributions, Ubuntu does not automatically remove 
>>> older, unused kernel packages after an update. Over time, this will fill 
>>> the boot partition and result in future updates failing.

The email continued, recommending that we clean up old Ubuntu kernels
using this command:
  # dpkg --get-selections|grep 'linux-image*'|awk '{print $1}'|egrep
-v "linux-image-$(uname -r)|linux-image-generic" |while read n;do
apt-get -y remove $n;done

Truly, I connected to several of my Ubuntu servers, some of which have
been running for over 4 years, and I manually purged 3GB+ of old
kernels on some machines!

I don't want to go into all the ways and reasons that the one-liner
above is sub-optimal or even evil, but I would like to call attention
to the generic problem and suggest that as a distribution, we provide
a supported and recommended utility to handle this.

I asked about this in IRC yesterday, and Colin Watson pointed me to
the computer-janitor utility, which is intended to handle this.
Seconds later, Barry Warsaw told me that computer-janitor should die
:-)  I tried computer-janitor on my desktop, and it seemed to work
okay.  But then I tried it on my servers and it failed:
  # sudo computer-janitor find
  ERROR:dbus.proxies:Introspect error on :1.3:/:
dbus.exceptions.DBusException:
org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 1
matched rules; type="method_call", sender=":1.8" (uid=0 pid=26155
comm="/usr/bin/python /usr/sbin/computer-janitor find ")
interface="org.freedesktop.DBus.Introspectable" member="Introspect"
error name="(unset)" requested_reply="0" destination=":1.3" (uid=0
pid=19905 comm="/usr/bin/python /usr/share/computerjanitor/janitor")

So I guess my questions are:
 1) Surely we're not the only Ubuntu users whose /boot or root
partition has filled up with age-old kernels, are we?
 2) Is computer-janitor here to stay, or to be abandoned in favor of
something else?
 3) Can we expect computer-janitor to work on command-line only
environments (Ubuntu servers) too?  If so, can we get SRUs out so that
it works on older distributions?
 4) Can we, as a distro, provide and recommend a utility to clean out
specifically old kernels (perhaps aside from cleaning up userspace
cruft a la computer-janitor)?

-- 
:-Dustin

Dustin Kirkland
Ubuntu Core Developer

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: motd.tail renamed itself to motd.tail.old in all of my servers at the same time

[Dustin Kirkland]

On Thu, Feb 16, 2012 at 4:19 AM, Alberto Fuentes
 wrote:
> suddenly all of my servers stopped showing /etc/motd.tail i noticed in some
> of the it got renamed to motd.tail.old... after a few minutes, it started
> working again.
>
> I googled a little bit the issue without luck...
>
> Does anybody know what happened?

On Thu, Feb 16, 2012 at 4:19 AM, Alberto Fuentes
 wrote:
> suddenly all of my servers stopped showing /etc/motd.tail i noticed in some
> of the it got renamed to motd.tail.old... after a few minutes, it started
> working again.
>
> I googled a little bit the issue without luck...
>
> Does anybody know what happened?

It's possible that you upgraded your base-files package from a version
older than 5.0.0ubuntu13.  In its postinst script, it does:
...
if [ "$1" = "configure" ] && [ "$2" != "" ]; then
  if [ -f /etc/motd.tail ]; then
if dpkg --compare-versions "$2" lt-nl 5.0.0ubuntu13; then
  # motd.tail is no longer generated by this package;
  # rather, the sysadmin can use motd.tail to append
  # text to the pam_motd dynamically generated motd
  mv -f /etc/motd.tail /etc/motd.tail.old
  # Clear out old MOTD, will be regenerated on next login
  rm -f /var/run/motd
fi
  fi
...
fi

-- 
:-Dustin

Dustin Kirkland
Ubuntu Core Developer

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Stepping Down

[Dustin Kirkland]

On Mon, Aug 1, 2011 at 4:56 PM, Adam Sommer  wrote:
> Hello,
> I am regrettably submitting my public resignation from active participation.
>  It's been a long time coming, and I've been optimistically holding on to
> the hope that I could find more time for Ubuntu activities.  I apologize for
> taking so long, and hope that I haven't jammed anyone up in any way.  The
> past few cycles I have had increasingly less time to devote to Ubuntu
> participation, and I've finally faced the fact that the situation won't
> change in the near future.  I still plan to use and follow Ubuntu
> development, possibly contributing small changes as time allows.
> I would like to thank all the great friends I have made during the last four
> years as part of the Ubuntu community.  It has a been a great time and very
> enriching part of my life.  It is impossible to put into words what the
> opportunities and relationships have meant to me.  It has been a truly great
> experience, and I hope to someday have the resources to actively participate
> in the community once again.
> In the mean time please don't hesitate to friend me up, follow, place in
> circles, etc.  I may be on pause, but I'm still out there :-).
> Thank you all once again!
>
>
> --
> Party On,
> Adam

Hi Adam,

Sorry to hear that, but I do want to thank you oh so much for your
awesome contributions to the Linux Server Guide and Documentation!
You really filled a niche there, something we've always needed in the
Ubuntu Server world!

Going to miss that sign off, too :-) "Party on, Wayne" :-)

See ya around,
-- 
:-Dustin

Dustin Kirkland
Ubuntu Core Developer

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Proposal for weekly Ensemble releases into Oneiric

[Dustin Kirkland]

On Fri, Jul 15, 2011 at 10:10 AM, Clint Byrum  wrote:
> Excerpts from Robbie Williamson's message of Mon Jul 11 16:26:36 -0700 2011:
>> Hi all,
>>
>> Given the rapid pace of development with ensemble, and the needs of
>> people trying to build solutions with it in Oneiric, I would like to
>> propose that we implement a weekly release schedule for ensemble, and
>> the related packages in the ensemble PPA, for Ubuntu.  This approach
>> really helped with Unity integration in Desktop, which was (and still is
>> in some ways) a rapidly advancing project.  I'm not familiar with the
>> details of the ensemble daily build PPA, but "in theory", I imagine it
>> would simply be syncing from it on a weekly cadence.  I think Monday, or
>> possibly Tuesday, is the best day of the week, so as not to collide with
>> any releases or freezes.  Thoughts?  Can someone take this effort on?
>
> Good plan.
>
> Unless anybody has any red flag on this, I'll go ahead and do this every
> Tuesday.  I'm also going to start linking specific bugs to the Ubuntu
> package that need to get fixed in 11.10, and will encourage others to
> do so. If there are Critical open bugs in upstream, I will delay the
> weekly release until they are closed.

Excellent. +1 from the SI Team.  We'll make sure our blocking bugs are
tagged/targeted appropriately.

-- 
:-Dustin

Dustin Kirkland
Manager, Systems Integration
Corporate Services
Canonical, LTD

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: [Oneiric-Topic] Byobu

[Dustin Kirkland]

On Fri, Apr 1, 2011 at 2:12 PM, Clint Byrum  wrote:
> I took your statement of "we'll have almost everything we need." to
> mean, we'll have almost everything we need to make it the default
> terminal shell.

Hey Clint, one important clarification here.  Just need to update the
vocabulary here...

This isn't about byobu as a "default shell".  Byobu/screen is not a
shell itself, but rather a "command line window manager".  It's a
program that runs within a shell, and allows you to launch and manage
dozens (40, by default) of shells within a single user process.

Your default shell is bash, or dash, ash, csh, tsh, ksh, etc. etc.
etc.  All of those do (or at least should -- file bugs if not) work
just fine under Linux.  Ubuntu chooses a default user shell of bash
for you.  There's no intention to change that.

The way "byobu at login" currently works is by adding a line to the
very end of your ~/.profile:
  case "$-" in *i*) byobu-launcher && exit 0; esac;

This says "if the shell being launched is interactive, then run byobu
and exit when byobu is done".  There is always room for improvement
there, and that's part of what a blueprint would design and fix.

Anyway, this is an interesting point in the thread.  I'm going to put
together a blog post that actually walks through all of what happens
when you login into an Ubuntu command line shell, from a low-level
technical perspective ;-)

-- 
:-Dustin

Dustin Kirkland
Ubuntu Core Developer

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: [Oneiric-Topic] Byobu

[Dustin Kirkland]

On Fri, Apr 1, 2011 at 3:50 PM, Clint Byrum  wrote:
> Presumably this would only be enabled in the /etc/skel default bashrc,
> and so, existing users would not suddenly see byobu on their next login.

There are several different ways to handle it, but I was thinking
about using the debconf/preseed element that's been in byobu since
Lucid, byobu/launch-by-default, which is currently defaulted to
"false".

I think we could handle the upgrade situation cleanly with logic in
the config and postinst parts of the debconf handling.

-- 
:-Dustin

Dustin Kirkland
Ubuntu Core Developer

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: [Oneiric-Topic] Byobu

[Dustin Kirkland]

On Fri, Apr 1, 2011 at 2:12 PM, Clint Byrum  wrote:
> I opened a bug to get some feedback:
>
> https://bugs.launchpad.net/ubuntu/+source/byobu/+bug/747649

Perfect, thanks!

> I think its well documented and works fine. My main concern is that it
> interrupts the normal flow to have to logout and back in to disable the
> nesting.

Good point.  I have a few ideas about that too, and some prototype
code that would allow you to detach from byobu/screen, but still be in
a shell (rather than the current default detach && exit).

BTW, you can modify the behavior of byobu, as to whether it detaches
and exits, or just detaches (and leaves you at a shell).  Simply use:
 $ byobu-launcher-install --no-logout

See for details:
 * http://manpages.ubuntu.com/byobu-launcher-install

> Thats sort of the opposite of all those who haven't started using byobu
> yet, whom we're suggesting may be opted in to it soon.

Great point.  I need you and others point out those sorts of things to
me and other 2nd-nature byobu users.

> This one isn't a total deal killer. I am concerned that going forward w/o
> some plan for how to handle nested sessions smoothly would be a missed
> opportunity to give a lot of users a really great first impression
> of byobu.

Ack.  100% agree.

> Count me in for a session about byobu development.

\o/

-- 
:-Dustin

Dustin Kirkland
Ubuntu Core Developer

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: [Oneiric-Topic] Byobu

[Dustin Kirkland]

On Fri, Apr 1, 2011 at 11:48 AM, Clint Byrum  wrote:
> Excerpts from Dustin Kirkland's message of Fri Apr 01 07:08:31 -0700 2011:
>> 2011/4/1 Raphaël Pinson :
>> > Also, a few years back, I had begun to work on making screen ACLs
>> > easier in byobu, but had not found the time to finish that part. Since
>> > Ubuntu encourages the use of user accounts vs root, this is a feature
>> > that could be very useful on Ubuntu servers I think.
>>
>> That's a great idea, Raphael.  Actually, I was talking with Dave
>> Walker about this recently.  Basically, I'm just going to move the
>> screen configuration magic from screenbin into byobu, and I think
>> we'll have almost everything we need.
>>
>
> Maybe I'm missing something here.. but this seems to happen to me
> whenever I enable "byobu by default" (last time I did this in earnest
> was for a week around 10.10 beta1, but I simluated it again just now on
> natty beta1 to confirm its still this way):

Clint,

We're talking about two different things.  What you're talking about
is the behavior of one system user on the system, logging in multiple
times, from multiple different places.

We're talking about GNU screen's built in ACL feature, where one user
can share a session (optionally with read/write, or read/only) to a
different system user.  So user 'kirkland' could share his session
with user 'Spamaps', or 'guest'.

> [ from inside byobu ]
> clint@laptop:~$ sshlucid-box-that-has-byobu-on
>
> I know that had it been a later release it would ask me about the nested
> session. I am not sure that is all that great as well, how about just
> making the default answer N and not even asking? I know sometimes you
> do want a nested session... but I'd bet guess thats a special case and
> usually not what users want, and is handled very well by running 'byobu'
> Even a simple echo 'You have an active byobu session..' would be better
> than stopping to ask me a question.

Interesting.  Sure, we can make that configurable, at the very least.
And we should absolutely discuss the most sensible default behavior.
That's absolutely a valid point, and something that should definitely
be reconsidered.

> Anyway, since this is a lucid remote box, now I have *4* lines of byobu
> hotness at the bottom. Also I hit F2 to go to the next window. OOPS,
> my ssh session disappeared because I'm only controlling the local
> byobu. I want to scroll back on the remote machine to see what I did
> 5 minutes ago. Oops, the scrollback capabilities are gone because my
> local terminal has been told its got a window now. Ctrl-A-A-ESC will
> get me into the screen backscroll/copy/paste mode, but by this time,
> honestly.. I'm very, very annoyed and just want my bash back.

You can *always* get around byobu launching by default by running:

 $ ssh -t remotehost bash

I use this frequently when ssh'ing elsewhere from within Byobu, if I
don't want a nested session.  This probably needs to be documented
better.

> Until the mechanics flow between terminals and ssh sessions in a way
> that makes sense to me, I'll find it very hard to be a +1.

Fair enough.  It's really just a matter of knowing where you are, and
how to drive.  It's second nature to me, at this point.

> Has there been any thought given to focusing on making byobu work in
> a more client/server way where a remote byobu knows it is talking to
> a byobu terminal, and so can integrate well into it (so add its status
> to the local byobu rather than adding another status line.. and letting
> f-keys be split between local / remote).
>
> THAT would make it smooth, and would probably turn me into a fan.

To be honest, no I haven't given much thought specifically about it,
though that sounds like a great topic for Oneiric byobu development.

The code that currently handles this (in case you want to toy with it
yourself) is in /usr/bin/byobu-launcher.  See the:
  case "$TERM" in *screen*) #handle nesting ...
section of that shell script.  This is where we could do something smarter.

Thanks for the feedback, Clint!

-- 
:-Dustin

Dustin Kirkland
Ubuntu Core Developer

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: [Oneiric-Topic] Byobu

[Dustin Kirkland]

On Fri, Apr 1, 2011 at 9:22 AM, Serge E. Hallyn  wrote:
> Quoting Dustin Kirkland (kirkl...@ubuntu.com):
>> 2011/4/1 Raphaël Pinson :
>> > Also, a few years back, I had begun to work on making screen ACLs
>> > easier in byobu, but had not found the time to finish that part. Since
>> > Ubuntu encourages the use of user accounts vs root, this is a feature
>> > that could be very useful on Ubuntu servers I think.
>>
>> That's a great idea, Raphael.  Actually, I was talking with Dave
>> Walker about this recently.  Basically, I'm just going to move the
>> screen configuration magic from screenbin into byobu, and I think
>> we'll have almost everything we need.
>
> Use of acls requires a setuid-root screen binary, though, right?  That's
> a huge change.

Correctly I identified, Serge!  You have dug into the "almost" in the
"we'll have almost everything we need" statement above :-)

So here's what I'm thinking ...

 1) Byobu would ship a profile in /usr/share/byobu/profiles/sharing
that has the relevant configuration bits.  Top of my head, that's
mostly this (where the guest user is called "guest").  I'll need to do
some work to make this configurable.

aclumask guest+r guest-w guest-x
aclchg guest +r-w-x '#?'
aclchg guest +x 'prev,next,select,detach'
multiuser on

 2) Byobu would add a dialog to the F9:Menu that allows you to choose
the user you want to share the screen with, and select read-only or
read-write.  It would also run something like
'/usr/bin/byobu-verify-sharing' and check the exit code and stderr
text.

 3) /usr/bin/byobu-verify-sharing would check the permissions on
/usr/bin/screen.  If the permissions are incorrect, it would print
some text to the screen that your system administrator would need to
run in order to use screen sharing.  Again, top of my head it might
look something like this:

$ byobu-verify-sharing
ERROR: byobu screen sharing is not enabled
INFO: (1-2 lines here about setuid binaries, and why screen is not
setuid by default)
INFO: To enable byobu screen sharing, a system administrator must run:
 sudo dpkg-statoverride --add root utmp 6755 /usr/bin/screen
 sudo chmod 755 /var/run/screen
$ echo $?
1

 4) We could also add a "low" debconf question to the screen (or
byobu) package that asks this question at dpkg-reconfigure time (do
you want to enable screen sharing, setuid bits, on /usr/bin/screen).

Anyway, that's what I'm thinking.  Any other ideas?

-- 
:-Dustin

Dustin Kirkland
Ubuntu Core Developer

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: [Oneiric-Topic] Byobu

[Dustin Kirkland]

2011/4/1 Raphaël Pinson :
> Also, a few years back, I had begun to work on making screen ACLs
> easier in byobu, but had not found the time to finish that part. Since
> Ubuntu encourages the use of user accounts vs root, this is a feature
> that could be very useful on Ubuntu servers I think.

That's a great idea, Raphael.  Actually, I was talking with Dave
Walker about this recently.  Basically, I'm just going to move the
screen configuration magic from screenbin into byobu, and I think
we'll have almost everything we need.

-- 
:-Dustin

Dustin Kirkland
Ubuntu Core Developer

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Ubuntu Server hardware requirements...

[Dustin Kirkland]

On Thu, Mar 31, 2011 at 2:43 AM, Clint Byrum  wrote:
> https://help.ubuntu.com/community/Installation/SystemRequirements
>
> This states the following requirements for running Ubuntu Server:
>
>  * 300 MHz x86 processor
>  * 128MB of system memory (RAM)
>  * 1GB of disk space
>  * Graphics card and monitor capable of 640x480
>  * CD-ROM drive
>
> The first one is somewhat funny, as I think there were only a few early
> Pentium II's and PentiumPro's that ran at 300Mhz. Since we dropped i586
> support in Maverick, might we also think about raising this to say,
> 450Mhz ?
>
> Also while there are things one can do w/ 128MB of RAM on Ubuntu
> Server.. is it a realistic minimum?
>
> Do we actually require a graphics card? If you are clever you can get
> the alternative installer to install via serial console IIRC.

Correct.  For reference I was able to install Natty just now in a KVM
with no VGA with the following:

kvm -cdrom natty-server-amd64.iso -kernel vmlinuz -initrd initrd.gz
--append "console=ttyS0 priority=critical locale=en_US
url=http://bit.ly/uquick"; -vga none -serial stdio

Note that I loop mounted the iso to extract vmlinuz and initrd.gz,
which are required if you use kvm's --append.  If you haven't done
this before, running the Ubuntu Installer in a virtual machine on a
command line over SSH is kind of fun :-)

-- 
:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: [Oneiric-Topic] Server Boot

[Dustin Kirkland]

On Wed, Mar 30, 2011 at 1:00 PM, Clint Byrum  wrote:
> On Wed, 2011-03-30 at 10:49 -0400, Douglas Stanley wrote:
>> On Wed, Mar 30, 2011 at 8:52 AM, Serge E. Hallyn
>> > I think right now these issues are oveshadowed by the fact that a
>> > great deal of server software is not yet upstartified.  I think that
>> > needs to be addressed for O.
>>
>> I agree, it can get confusing when for example restarting some
>> services, I do restart, and for others I have to do the older
>> /etc/init.d/service restart. I miss the days when it was all uniform
>> :)
>>
>> Even if there was at the least, some kind of wrapper, so when I did
>> restart servicexyz, if that service wasn't upstartified, it just ran
>> the init script restart for me...
>>
>
> There is a wrapper, and has been for a long time:
>
> service X restart
>
> Will do the right thing, and figure out if the service has been
> upstart-ified or not.

And if that doesn't work well, let us know!  I try to keep
/sbin/service in tip-top shape ;-)

-- 
:-Dustin

Dustin Kirkland
Ubuntu Core Developer

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

[Oneiric-Topic] Ubuntu Orchestra

[Dustin Kirkland]

A series of similarly themed blueprints from UDS-Natty in Orlando were
subsequently combined into a single blueprint [1] in the Natty cycle.

As of 11.04, we have several of the key building blocks now packaged
in the Ubuntu archive (cobbler, mcollective, etc).  And we have a
branch at lp:orchestra that provides the basic meta packaging for
pieces we want to implement using the best of free software:
 * Provisioning / Installation Services
 * Configuration Management
 * Monitoring
 * Orchestration

There are several limitations to stock ISO-based installs (eg, another
thread here raises the issue of the limited ISO capacity).  A complete
network installation service is essential to the future of Ubuntu
Server efforts.  I envision a situation where the first step in
deploying a set of Ubuntu Servers is to install the Ubuntu Orchestra
Provisioning server (apt-get install
ubuntu-orchestra-provisioning-server, or perhaps run a temporary
deploy server from a LiveUSB).  Subsequent installations in the
hundreds or thousands are rapidly and flexibly bootstrapped directly
from the provisioning server.

Our OpenStack integration efforts for 11.10 will require some
installation modifications similar to what we did in 9.10 for
Eucalyptus and UEC.  Rather than hacking through the guts of the
debian-installer again for this work, I suggest that we build
OpenStack's installation on top of a modern network installation
service, as serious cloud deployments necessarily require the
installation of more than one system.  (Note that OpenStack already
has a prototype of such a service with the Crowbar project.)

A web/network-based installation service would allow the Ubuntu Server
to modernize its interface and handle far more installation modes and
workloads than an 80x25 teletype terminal can deliver.  It would give
the Server Team the ability to integrate new software stacks such as
OpenStack easily within a single Ubuntu development cycle, something
that's simply not possible when integral debian-installer changes are
required (the tasksel menu is the only hook really at our disposal
right now).  The combination of dynamically generated preseed
configurations coupled with config-management based post installation
handling would provide a modern, DevOps-style interface to Ubuntu
Server installations, and is key to our future.

[1] https://blueprints.launchpad.net/ubuntu/+spec/cloud-server-n-install-service

-- 
:-Dustin

Dustin Kirkland
Ubuntu Core Developer

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: [Oneiric-Topic] Further PowerNap Improvements

[Dustin Kirkland]

On Wed, Mar 30, 2011 at 9:57 AM, Andres Rodriguez  wrote:
> Hi All,
> During the Natty release cycle, PowerNap was improved in two main aspects:
>  - Monitoring enhancements, adding the capability to monitor different
> components such as Input, Network Activity and Application activity to
> correctly determine the idled state of the machine.
>  - New Power Saving method, consisting on using pm-powersave and providing a
> few additional scripts.
> However, now. I'd like to see a Client/Server implementation approach of
> PowerNap on which things occur as follows:
>  - Client auto-registration to a PowerNap server
>  - PowerNap server tracking the status of a PowerNap client in the network.
>  - PowerNap server being able to schedule wakeups-sleeps for any of the
> clients.
>  - PowerNap server being able to monitor network to auto wakeup monitored
> machines (i.e. ARP Monitor)
>  - API like base implementation to be able to integrate it to
> other applications, (i.e. Landscape.)

These are good, Andres.

Additionally, I would like to see the current PowerNap monitors which
are still polling to be moved to an event-based model, where possible.

-- 
:-Dustin

Dustin Kirkland
Ubuntu Core Developer

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Cobbler on Natty Alpha 3

[Dustin Kirkland]

On Thu, Mar 24, 2011 at 7:25 AM, Jamie McDonald  wrote:
> Afternoon,
>
> Perhaps everyone knows this but I've had trouble getting Cobbler to work
> correctly on 10.04 LTS. I spoke with someone on IRC and they said alot of
> effort had been going into Cobbler for Natty.
>
> As a result I tried to get it working under Natty Alpha 3 in a VM and found
> the Web UI did not work correctly using the default package.
>
> I've outlined the steps required to make it work in the hope it might help
> someone else.
>
> ##
> Cobbler inital config on natty-alpha3
> ##
>
> apt-get install cobbler
> a2enmod proxy_http
> cd /etc/apache2/conf.d
> ln -s /etc/cobbler/cobbler_web.conf cobbler_web.conf
>
> Edit cobbler_web.conf and comment out line 9 so it reads
>  -
>  #CustomLog logs/access_log combined env=!dontlog
>  -
>
> cd /var/www
> rm cobbler_webui_content
> ln -s /usr/share/cobbler/webroot/cobbler_webui_content/
> cobbler_webui_content
>
> ##
> Configure cobbler to allow logins
> ##
> Edit /etc/cobbler/modules.conf
>
> Change the line which reads
>  -
>   [authentication]
>   module = authn_denyall
>  -
>
> So that it actually says
>
>  -
>   [authentication]
>   module = authn_configfile
>  -
>
> ###
> Now add a user
> ###
> htdigest /etc/cobbler/users.digest "Cobbler" myusername
>
> #
> Restart all services
> #
> service apache2 stop
> service cobbler stop
> service apache2 start
> service apache2 start
>
> I've also posted this as a bug for the package in Launchpad:
> https://bugs.launchpad.net/ubuntu/+source/cobbler/+bug/741661
>
> I hope this is the correct procedure? It's my first bug report so please let
> me know if I should do things differently in the future.
>
> Regards,
>
> Jamie.

Hi Jamie,

Thanks for your feedback!  We do have a goal of having a working
Cobbler out-of-the-box for Ubuntu 11.04, so your testing and
instructions are very valuable.  We'll take a look at this bug ASAP.

Thanks,
-- 
:-Dustin

Dustin Kirkland
Ubuntu Core Developer

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Call for testing: Aubergine-love for Server folks!

[Dustin Kirkland]

On Fri, Mar 18, 2011 at 1:54 PM, Scott Kitterman  wrote:
> On Thursday, March 17, 2011 10:01:51 pm Dustin Kirkland wrote:
>> Howdy Ubuntu-devel and Ubuntu-server,
>>
>> We just uploaded a couple of small patches a week ahead of
>> UserInterfaceFreeze to five packages that affect the console tty and
>> vt interface.  We're hoping you can help test this on your hardware
>> and let us know if you find any adverse affects (please subscribe me
>> to the bug reports, if you do!) :-)
>>
>> The end goals were (Bug #730672):
>>  1) Improve the virtual terminal color palette
>>  2) Modernize the visual experience on Ubuntu servers
>>
>> To solve (1), we wrote a small C program that you should now find in
>> /sbin/setvtrgb.  You can refer to the manpage for the full
>> documentation.  It's a handy utility that reads a set of well-formed
>> RGB values from file and then uses an ioctl to dynamically apply them
>> to all consoles.  This utility is currently provided in the kbd
>> package, and I'm working on getting that upstream into Debian.
>>
>> The default colors used by the Linux kernel are quite simply the
>> traditional 16 VGA colors, which you can find at:
>>  * http://en.wikipedia.org/wiki/ANSI_escape_code#Colors
>>
>> While perhaps mathematically symmetric, some of those colors are a
>> pretty hard on the eyes.  The Ubuntu Design Team has put quite a bit
>> of effort into selecting a distinctive color scheme for the Ubuntu
>> Desktop, and they have now carefully selected an 16 color palette for
>> server consoles too!
>>
>> So the next three pieces of (1) are solved by a series of uploads to:
>>  * console-setup -- add a conffile at /etc/vtrgb (so that you can
>> customize your own console colors, if you don't like the ones Ubuntu
>> provides!), and an upstart job that applies them on boot with
>> 'setvtrgb /etc/vtrgb'
>>  * rootskel -- call 'setvtrgb /etc/vtrgb' early in the Server and
>> Alternate installer for its virtual terminals
>>  * bogl -- update the colors in the bterm palette used by
>> debian-installer (it happens to hard code them)
>>
>> After upgrading your local system's kbd and console-setup packages,
>> you should now have a crisp, new, clean color scheme in your tty.
>> There should be no affect whatsoever in [X, Gnome, KDE, XFCE,
>> gnome-terminal, konsole] or even SSH sessions to your server.
>> However, if you drop to a command prompt with ctrl-alt-F1, you should
>> see a nice difference.  Note that if for some reason perhaps you
>> prefer the legacy VGA colors, you can revert the change simply with:
>>  $ sudo setvtrgb vga
>> And if you want to make that permanent, follow with:
>>  $ cat /sys/module/vt/parameters/default_{red,grn,blu} | sudo tee
>> /etc/vtrgb
>>
>> And as soon as the daily cdimage builder picks up the changes to
>> rootskel and bogl (within a day or two?), you should see the same
>> color improvements in the Natty Server and Alternate installer
>> screens.
>>
>> Now to address (2), we've made one minor change to the newt library,
>> which defines the color scheme for most curses-based utilities -- most
>> importantly, debconf and in turn, the debian-installer.  If you've
>> ever installed an Ubuntu server, and in staring at the screen thought,
>> "That blue sure looks a lot like MS-DOS circa 1988," we're right there
>> with you.  So we've swapped that aged "Microsoft blue" out for some
>> modern "Ubuntu aubergine"!
>>
>> So what does all of this look like?  Here are some screen shots!
>>  * On the console
>>   * before: http://bit.ly/fvm16s
>>   * after: http://bit.ly/dRF9yi
>>  * And in the installer
>>   * msdos6: http://bit.ly/gyQgJL
>>   * before: http://bit.ly/i1cc5Q
>>   * after: http://bit.ly/hRLDDI
>>
>> Spiffy, huh?  Thanks to everyone who help spread some Aubergine-love
>> to Ubuntu Server folks!
>
> So now every Ubuntu flavor gets Aubergine even though that's not their color
> scheme?

Until now, Ubuntu and all Ubuntu flavors have inherited a color scheme
wasn't theirs either, actually.

> How do we over-ride this for Kubuntu (there have been complaints on #kubuntu-
> devel today)?

I filed and fixed Bug: #730672, on your behalf.

The newt library can now read its palette from a configuration file,
which is installed using update-alternatives.
 +   update-alternatives --install /etc/newt/palette newt-palette
/usr/share/newt/palette.ubuntu 50
 +   update-alternatives --install /etc/newt/palette newt-palette
/usr/share/newt/palette 20

Furthermore, the console-setup package now also installs its color
scheme using update-alternatives as well.
 +update-alternatives --install /etc/vtrgb vtrgb
/usr/share/console-setup/vtrgb 50

Other packages can install palettes and different color schemes at
different priorities.

-- 
:-Dustin

Dustin Kirkland
Ubuntu Core Developer

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Call for testing: Aubergine-love for Server folks!

[Dustin Kirkland]

On Fri, Mar 18, 2011 at 10:50 AM, Loïc Minier  wrote:
> On Thu, Mar 17, 2011, Dustin Kirkland wrote:
>> After upgrading your local system's kbd and console-setup packages,
>> you should now have a crisp, new, clean color scheme in your tty.
>> There should be no affect whatsoever in [X, Gnome, KDE, XFCE,
>> gnome-terminal, konsole] or even SSH sessions to your server.
>
>  Like Bryce, I'm pleased that the stress on my eyes is likely to reduce
>  with these changes!  And like Timo, I think grey vs white isn't
>  obvious.

Hi Loic,

Thanks for the feedback.  I'll note that to Marcus and see if we can
find a slightly better grey.

>  I've been poking gnome-terminal colors often to try to improve this
>  myself; is there a plan to provide similar colors by default in
>  xterm/gnome-terminal/others?

That I'm not sure of.  But I, too, really like the idea!  I CC'd
Ivanka and Marcus on this response.  Perhaps they can tell us if they
have plans, or would consider using this palette or designing another
for xterm/gnome-terminal...  Ivanka?

Thanks,
-- 
:-Dustin

Dustin Kirkland
Ubuntu Core Developer

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Call for testing: Aubergine-love for Server folks!

[Dustin Kirkland]

Howdy Ubuntu-devel and Ubuntu-server,

We just uploaded a couple of small patches a week ahead of
UserInterfaceFreeze to five packages that affect the console tty and
vt interface.  We're hoping you can help test this on your hardware
and let us know if you find any adverse affects (please subscribe me
to the bug reports, if you do!) :-)

The end goals were (Bug #730672):
 1) Improve the virtual terminal color palette
 2) Modernize the visual experience on Ubuntu servers

To solve (1), we wrote a small C program that you should now find in
/sbin/setvtrgb.  You can refer to the manpage for the full
documentation.  It's a handy utility that reads a set of well-formed
RGB values from file and then uses an ioctl to dynamically apply them
to all consoles.  This utility is currently provided in the kbd
package, and I'm working on getting that upstream into Debian.

The default colors used by the Linux kernel are quite simply the
traditional 16 VGA colors, which you can find at:
 * http://en.wikipedia.org/wiki/ANSI_escape_code#Colors

While perhaps mathematically symmetric, some of those colors are a
pretty hard on the eyes.  The Ubuntu Design Team has put quite a bit
of effort into selecting a distinctive color scheme for the Ubuntu
Desktop, and they have now carefully selected an 16 color palette for
server consoles too!

So the next three pieces of (1) are solved by a series of uploads to:
 * console-setup -- add a conffile at /etc/vtrgb (so that you can
customize your own console colors, if you don't like the ones Ubuntu
provides!), and an upstart job that applies them on boot with
'setvtrgb /etc/vtrgb'
 * rootskel -- call 'setvtrgb /etc/vtrgb' early in the Server and
Alternate installer for its virtual terminals
 * bogl -- update the colors in the bterm palette used by
debian-installer (it happens to hard code them)

After upgrading your local system's kbd and console-setup packages,
you should now have a crisp, new, clean color scheme in your tty.
There should be no affect whatsoever in [X, Gnome, KDE, XFCE,
gnome-terminal, konsole] or even SSH sessions to your server.
However, if you drop to a command prompt with ctrl-alt-F1, you should
see a nice difference.  Note that if for some reason perhaps you
prefer the legacy VGA colors, you can revert the change simply with:
 $ sudo setvtrgb vga
And if you want to make that permanent, follow with:
 $ cat /sys/module/vt/parameters/default_{red,grn,blu} | sudo tee /etc/vtrgb

And as soon as the daily cdimage builder picks up the changes to
rootskel and bogl (within a day or two?), you should see the same
color improvements in the Natty Server and Alternate installer
screens.

Now to address (2), we've made one minor change to the newt library,
which defines the color scheme for most curses-based utilities -- most
importantly, debconf and in turn, the debian-installer.  If you've
ever installed an Ubuntu server, and in staring at the screen thought,
"That blue sure looks a lot like MS-DOS circa 1988," we're right there
with you.  So we've swapped that aged "Microsoft blue" out for some
modern "Ubuntu aubergine"!

So what does all of this look like?  Here are some screen shots!
 * On the console
  * before: http://bit.ly/fvm16s
  * after: http://bit.ly/dRF9yi
 * And in the installer
  * msdos6: http://bit.ly/gyQgJL
  * before: http://bit.ly/i1cc5Q
  * after: http://bit.ly/hRLDDI

Spiffy, huh?  Thanks to everyone who help spread some Aubergine-love
to Ubuntu Server folks!

Enjoy,
-- 
:-Dustin

Dustin Kirkland
Ubuntu Core Developer

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: JeOS and ISCSI ISO testcases moved to optional

[Dustin Kirkland]

On Thu, Feb 17, 2011 at 2:23 PM, Etienne Goyer
 wrote:
> Srly, I was pointing this it out because lots of people mistakenly think
> you need a big $$$ NAS/SAN to test iSCSI.  There are software solution
> for that, and they work.  Just saying.

Right.  Perhaps what we need, then, is to snapshot a working iSCSI vm
disk image that can be imported into virsh/virt-manager, and upload
that to the iso.qa.ubuntu.com site, along side the instructions.  That
way, the iSCSI target itself is static, and it's just thing we're
testing (the iSCSI initiator) that's varying.

> Sorry Robbie!  You guys are always so helpful, and I give nothing back.
>  Shame on me, really!  :)

Heh, well, if you could get just such a minimal iSCSI target image,
we'll store it somewhere and use it for the testing that you're asking
us to do ;-)

Cheers,

-- 
:-Dustin

Dustin Kirkland
Ubuntu Core Developer

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Do you need some Ubuntu packages?

[Dustin Kirkland]

Resending, fixing Scott's email address.

On Mon, Feb 7, 2011 at 8:42 AM, Dustin Kirkland  wrote:
> On Mon, Feb 7, 2011 at 1:23 AM, Christian Roessner
>  wrote:
>> Hi,
>>
>> I created Postfix-2.8.0 and Dovecot-2.0.9 packages. I tried to contact one 
>> of the other guys from Ubuntu, but did not get an answer. Have a look here:
>>
>> http://mysourceco.de
>>
>> Maybe you like to include it into upcoming Ubuntu version or the 
>> over-the-next one?
>
> Hi Christian,
>
> I have CC'd Scott Kitterman, and the Ubuntu Server Team, who maintain
> these packages in Ubuntu.  I think it will be up to them, more than
> me, as to whether these packages make it into Ubuntu 11.04.
>
> Thank you very much for your proposed contributions!
>
> --
> :-Dustin
>
> Dustin Kirkland
> Ubuntu Core Developer
>



-- 
:-Dustin

Dustin Kirkland
Ubuntu Core Developer

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Do you need some Ubuntu packages?

[Dustin Kirkland]

On Mon, Feb 7, 2011 at 1:23 AM, Christian Roessner
 wrote:
> Hi,
>
> I created Postfix-2.8.0 and Dovecot-2.0.9 packages. I tried to contact one of 
> the other guys from Ubuntu, but did not get an answer. Have a look here:
>
> http://mysourceco.de
>
> Maybe you like to include it into upcoming Ubuntu version or the 
> over-the-next one?

Hi Christian,

I have CC'd Scott Kitterman, and the Ubuntu Server Team, who maintain
these packages in Ubuntu.  I think it will be up to them, more than
me, as to whether these packages make it into Ubuntu 11.04.

Thank you very much for your proposed contributions!

-- 
:-Dustin

Dustin Kirkland
Ubuntu Core Developer

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: facter and KVM

[Dustin Kirkland]

Clint Byrum  wrote:
> On Tue, 2011-01-25 at 14:00 -0800, Mark Foster wrote:
>> On 01/25/2011 11:48 AM, Oliver Brakmann wrote:
>> > I'd like to ask for your opinion whether it would be worthwhile to file
>> > a bug on this.  On the one hand, this is fixed upstream already, on the
>> > other hand, both puppet and kvm are in main, and Lucid might benefit
>> > from an SRU.  Is this SRU worthy?
>>
>
> Yes it is, please do!
>
>> +1 since per https://wiki.ubuntu.com/StableReleaseUpdates it qualifies
>> for both of these criteria in my opinion.
>> # Bugs which do not fit under above categories, but (1) have an
>> obviously safe patch and (2) affect an application rather than critical
>> infrastructure packages (like X.org or the kernel).
>> # For Long Term Support releases we regularly want to enable new
>> hardware. Such changes are appropriate provided that we can ensure to
>> not affect upgrades on existing hardware. For example, modaliases of
>> newly introduced drivers must not overlap with previously shipped drivers.
>>
>> However it would also be necessary & wise to review the full change log
>> entries since there is likely way more changed in 1.5.8 (vs. 1.5.6 or 7)
>> than this one value change.
>
> Right, I'd suggest that we just cherry pick the patch, as long as it
> isn't too invasive.

I'd agree too.  Please make sure you file a bug and follow the rest of
those procedures described in that SRU wiki document, and this should
go painlessly.

Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: SSH and the Ubuntu Server

[Dustin Kirkland]

On Fri, Nov 19, 2010 at 4:50 PM, Dustin Kirkland  wrote:
> I'm going to redraft the proposal, note that there was no general
> consensus on the matter in the ubuntu-devel@ mailing list, and ask the
> Tech Board for guidance.  Thanks everyone for the lively discussion.

Thank you for the discussions at UDS, in IRC, and in this thread.

Colin's changes to the server tasksel (moving SSH to the top of the
list, albeit "unchecked") is a reasonable step towards improving the
usability of the server installer.

Let's just roll with this for now and evaluate its effectiveness next cycle.

Thanks again! :-)
:-Dustin

Dustin Kirkland
Ubuntu Core Developer

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: SSH and the Ubuntu Server

[Dustin Kirkland]

Stephan Hermann  wrote:
> Hi Scott,
>
> On Fri, 2010-11-19 at 13:18 -0500, Scott Kitterman wrote:
>> On Friday, November 19, 2010 12:02:33 pm Dustin Kirkland wrote:
>> > Confirmed this on RHEL6 yesterday.  I installed RHEL6 in multiple
>> > different modes (minimal, default, developer workstation), all of
>> > which a) were running sshd, b) had a root user with a password.
>>
>> Yes, but RHEL6 doesn't dhcp by default and Ubuntu Server does so the attack
>> surface for a default RHEL6 install is rather more limited.
>
> To be honest, there is no difference in installing RHEL6 with a static
> ip address or Ubuntu Server with DHCP enabled.
>
> I think we need to find out first, what user base we want to point at.
>
> The SysAdmin of a Company with Enterprise Classed Datacenter
> or the guy/gal from around the corner who is testing ubuntu server?
>
> The SysAdmin will have network security in place (if not..oh well), and
> mostly is he/she not using public IP addresses, and/or they setup their
> DHCPd to match the MACs of the NICs inside their servers.
>
> I am now wondering if we really should change something. As long as I'm
> thinking about the topic, I'm coming to my conclusion, that we just
> should tick sshd by default during tasksel in the installer, and that's
> it. For most of the admins out there, it really doesn't matter, because
> they have other ways to deploy ubuntu server on their servers.

I agree, Stephan.

The installer complexity can be avoided by just ticking the "OpenSSH
Server" in the top of the tasksel page as you suggest;  document that
change thoroughly and publish it far and wide; note the stronger
sshd.conf configurations from Marc and the security team in the SSH
help page.

Unfortunately, I don't think we're reaching a consensus here on ubuntu-de...@.

I'm going to redraft the proposal, note that there was no general
consensus on the matter in the ubuntu-devel@ mailing list, and ask the
Tech Board for guidance.  Thanks everyone for the lively discussion.

:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: SSH and the Ubuntu Server

[Dustin Kirkland]

Stephan Hermann  wrote:
> Moins,
>
> On Thu, 2010-11-18 at 12:24 -0500, Luke Faraone wrote:
>> On 11/18/2010 12:04 PM, Dustin Kirkland wrote:
>> > On Thu, Nov 18, 2010 at 9:30 AM, Colin Watson  wrote:
>> >> No, it's not.  In Maverick it was arguably buried.  In Natty, it is the
>> >> very top entry on the tasksel menu, and the cursor rests on it when you
>> >> reach that screen.
>> > [snip]
>> >
>> > I would gladly revise this proposal to simply:
>> >  * Automatically 'tick' OpenSSH Server by default on the Server Tasksel 
>> > screen
>> >
>> > Which would also sit there and wait for the user to consciously affirm
>> > their selection, and would avoid the countless server installations
>> > where people forget to install SSH and must make their way back to a
>> > console on their newly installed system and add the openssh-server
>> > package.
>>
>> As many people have mentioned, this will cause a surprise for users who
>> click through the install dialogs expecting things to not change since
>> they last used it.
>
> Sorry, but this is something which strucks me, really. When we don't
> change things over time, we will never  have a better user experience.
> When we change something it needs to be documented in a public place
> where everyone interested can read it first hand.

+1

>> Also, since this occurs late in the install process, no dialogs to
>> prompt the user to harden their password can be offered, as others have
>> suggested.
>
> Oh well, we can change that inside the installer as well. Not prompting
> for a user choice, but choosing a hardened password automatically and
> showing it to the user
> mkpasswd --chars=20 --crypt-md5 or whatever should be enough. that's
> only a technical problem easily to solve.
>
>
>> You say there are "countless" installations. I don't think anybody
>> expects SSH to be automatically installed in a new server; it's a
>> service that should be enabled carefully after consideration of your
>> network environment and security needs. I feel that the potential for
>> harm of accidental installation exceeds the increase in convenience from
>> not having to explicitly select the task.
>
> I think we have more installations of RHEL or SLES in the enterprise
> server market, and they do have sshd enabled by default.
> Even when you install an VMWare ESX host, ssh is enabled by default,
> without the questionable root access.

Confirmed this on RHEL6 yesterday.  I installed RHEL6 in multiple
different modes (minimal, default, developer workstation), all of
which a) were running sshd, b) had a root user with a password.

Simply the fact that Ubuntu does not have an active root password by
default means that network attacks via ssh must guess BOTH the
username AND the password.

Choose both wisely and you should be able to repel attacks between the
time that your new Ubuntu Server reboots for the first time and the
time it takes for you to login for the first time and configure
sshd.conf to your liking.  If you're actively working the
installation, we're talking less than 5 minutes.  If you've automated
the deployment via puppet or somesuch, it can be far less than that.

:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: SSH and the Ubuntu Server

[Dustin Kirkland]

On Thu, Nov 18, 2010 at 9:30 AM, Colin Watson  wrote:
> (Please, in future, do not cross-post between the moderated ubuntu-devel
> and the unmoderated ubuntu-devel-discuss.  Doing so produces time lags
> which confuse people.)

Dang.  Sorry, Colin.  Live and learn.

> On Wed, Nov 17, 2010 at 03:38:53PM -0600, Dustin Kirkland wrote:
>> I am asking for ubuntu-devel's consensus, and an eventual Ubuntu
>> Technical Board approval of a new prompt in the Ubuntu Server ISO's
>> text-based installer, which would read something like the following:
>>
>>  --
>> |  If you need a secure connection to this
>> |  server remotely, you may wish to install
>> |  the openssh-server package.  Note that
>> |  this service will open TCP port 22 on
>> |  your system, and you should use a very
>> |  strong password.
>> |
>> |  Do you want to install the SSH service?
>> |
>> |        [[YES]]        [no]
>>  --
>>
>> Rest assured that the exact text will be word-smithed by an
>> appropriate committee to hash out an optimum verbiage.
>
> Without wishing to express any opinion either way: this is an
> excessively painful choice of implementation.  If you want to default it
> to yes, it would be sufficient, and much easier (take it from me, I'm
> the one who gets to deal with the translation merge workload when you
> guys add questions ...) to check the "SSH server" entry in tasksel by
> default.
>
>> These key points map to the following considerations:
>>  1) the current option to install SSH on Ubuntu servers is buried in
>> the tasksel menu
>
> No, it's not.  In Maverick it was arguably buried.  In Natty, it is the
> very top entry on the tasksel menu, and the cursor rests on it when you
> reach that screen.

Right, that's a great change.  Makes it more obvious.

I can concede your point that adding the proposed page to the
installer would create work for you, which of course, is not my goal.

I would gladly revise this proposal to simply:
 * Automatically 'tick' OpenSSH Server by default on the Server Tasksel screen

Which would also sit there and wait for the user to consciously affirm
their selection, and would avoid the countless server installations
where people forget to install SSH and must make their way back to a
console on their newly installed system and add the openssh-server
package.

:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: SSH and the Ubuntu Server

[Dustin Kirkland]

I inadvertently left ubuntu-server@ off of the original distribution.

Sorry about that.  CC'ing now.

There are a few responses already in the thread:
 * https://lists.ubuntu.com/archives/ubuntu-devel/2010-November/thread.html

Thanks,
Dustin

On Wed, Nov 17, 2010 at 3:38 PM, Dustin Kirkland  wrote:
> Ubuntu has long maintained a "no open ports by default" policy.  This
> conservative approach arguably yields a more secure default
> installation.  Several exceptions have been granted to this policy,
> which install services on the target system without the user's
> explicit consent, but in the calculated interest and support of a
> vastly more usable Ubuntu.
>
> Let me be clear: I am NOT requesting that sort of an exception.
>
> I am asking for ubuntu-devel's consensus, and an eventual Ubuntu
> Technical Board approval of a new prompt in the Ubuntu Server ISO's
> text-based installer, which would read something like the following:
>
>  --
> |  If you need a secure connection to this
> |  server remotely, you may wish to install
> |  the openssh-server package.  Note that
> |  this service will open TCP port 22 on
> |  your system, and you should use a very
> |  strong password.
> |
> |  Do you want to install the SSH service?
> |
> |        [[YES]]        [no]
>  --
>
> Rest assured that the exact text will be word-smithed by an
> appropriate committee to hash out an optimum verbiage.
>
> This proposal requests that:
>  1) a new prompt be added to the Ubuntu Server installer
>  2) this prompt be dedicated to the boolean installation, or
> non-installation, of the SSH service, as an essential facet of a
> typical server
>  3) the cursor highlights the affirmative (yes, please install SSH),
> but awaits the user's conscious decision
>
> These key points map to the following considerations:
>  1) the current option to install SSH on Ubuntu servers is buried in
> the tasksel menu
>    - SSH is more fundamental to a server than the higher level
> profile selections for:
>      DNS Server, Mail Server, LAMP Stack, Virtualization Host, etc.
>  2) users of the installation ISO will have the option to not install
> SSH, as they so desire
>    - it is quite well understood that some users may not want SSH
> installed on their server
>  3) highlighting the "YES" option on this page is absolutely essential
> to addressing this usability issue
>    - and that selection is easily overridden by hitting ,
> or by experienced admins in preseed configurations
>
> Please consider that the very definition of a "server" implies that
> the system is running a "service".  Moreover, our official Ubuntu
> Server images as published for the Amazon EC2 cloud are, in fact,
> running SSH by default listening on port 22 on the unrestricted
> Internet (the 'ubuntu' has no password), and the Ubuntu Enterprise
> Cloud installation by the very same ISO installs SSH on every every
> UEC system deployed.  This is not unprecedented.
>
> Having discussed the proposal with a subset of this audience (at UDS
> and in IRC), here are some known FAQs:
>
>  Q: WTF?!?  Ubuntu has no open ports by default!
>  A: That depends on which "Ubuntu" you mean.  Ubuntu-in-the-cloud runs
> SSH.  Ubuntu-as-the-cloud runs SSH.  Ubuntu desktops run avahi.  Most
> importantly, this is not a "run by default" proposal.  We have already
> compromised on that subject, culminating in this proposal, which is
> simply about providing Server users with an obvious way to install the
> typically essential SSH service.
>
>  Q: Why not default the cursor on that question to "No", instead of "Yes"?
>  A: That totally bypasses the value of this proposal, and is only
> microscopically better than what we currently have, where Ubuntu
> Server users must go out of their way to add one of the most
> fundamental packages to almost any server installation.  The proposal,
> as it stands, is already a compromise from the original suggestion at
> UDS; which was, "if you're installing a server, you're expecting to
> run a service, so let's just install SSH by default".  That idea is
> entirely out of scope now.  We are proposing this installer question
> as a reasonable compromise.
>
>  Q: What if the openssh-server package is compromised on the ISO?
>  A: Although this has happened before, it is relatively rare over the
> history of Ubuntu.  If/when this happens again, we would need to:
>    a) recommend that people choose "no" when prompted, and install
> SSH post-in

Re: how to save bandwidth while package upgrades

[Dustin Kirkland]

On Tue, Nov 16, 2010 at 3:02 AM, Tapas Mishra  wrote:
> Here is a mail in /var/mail/root which I received in my server logs
> http://paste.ubuntu.com/532866/
> I see same packages downloaded many times again and again.
> The servers which are upgrading are total 5 (4 virtual machines and one host)
> so is there a way I can save bandwidth on this sort of setup.

Your question and the various responses inspired me to finally post my
solution to this problem:
 * http://blog.dustinkirkland.com/2010/11/yet-another-ubuntu-archive-proxy.html

Pasted here, in part:

Here's my solution...

To install, simply:
sudo apt-get install approx

Then set the URLs you want to proxy, in /etc/approx/approx.conf:
ubuntu http://archive.ubuntu.com/ubuntu
ubuntu-security http://security.ubuntu.com/ubuntu

I configured my proxy machine to listen on port 80:
sudo dpkg-reconfigure approx

Next, I took a little shortcut on my dd-wrt router's DNSMasq options,
so that I don't have to configure to each and every one of my guests
to point to my local mirror. I want that to happen automatically and
transparently to my guests. So I set my router to authoritatively
serve my local proxy's IP address as the resolution for
archive.ubuntu.com and security.ubuntu.com. The additional DNSMasq
options for me are:
  address=/archive.ubuntu.com/security.ubuntu.com/10.1.1.11
where "10.1.1.11" is my proxy's static IP address.

This ensures that all of my guests transparently use my local proxy,
without having to perform custom configuration on each.

Now on the proxy itself, I don't want archive.ubuntu.com to point to
the localhost, as that won't work very well at all! So for that one
machine, I changed its DNS to point to Google's Public DNS at 8.8.8.8.
echo "nameserver 8.8.8.8" | sudo tee /etc/resolv.conf

Alternatively, I could manually set the IP address of
archive.ubuntu.com and security.ubuntu.com in that machine's
/etc/hosts.

Moreover, if I ever need to disable the use of the caching proxy on a
single guest, I can simply and temporarily change that machine's DNS
to 8.8.8.8 as above.

I'm really finding this to be a handy way of speeding up my network
installs and package upgrades on my set of Ubuntu machines at home.
I'm not wasting nearly as much disk space or network bandwidth, and I
don't have to configure anything on each and every client or
installation.

:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Ubuntu Server Team Meeting Minutes from 2010-10-05

[Dustin Kirkland]

For more details, see:
 * https://wiki.ubuntu.com/MeetingLogs/Server/20101005

== Minutes ==
 Meeting Actions 
  * ACTION: mathiaz to send out a call for ideas on ubuntu to the
puppet community
  * ACTION: smoser to get skaet info on how to publish EC2 images
  * ACTION:  Everyone to celebrate the 10.10.10 release in their own unique ways

 Review ACTION points from previous meeting 
 * jiboumans to send an email to ubuntu-server@ and/or blog post for
call for ideas
   * DONE (during the course of the meeting)
  * mathiaz to send out a call for ideas on ubuntu to the puppet community
   * ACTION (held over to next week)

 Maverick development (jib) 
  * jib: winding down, ttx in London for release sprint

 release status, the road to 10.10.10 release (ttx) 
  * ttx: nothing critical, a few FTBFS, nothing queued against the
release, ISO testing to begin soon
  * ACTION: smoser to get skaet info on how to publish EC2 images

 Natty preparation (jib) 
  * jib: [[ServerTeam/NattyIdeaPool]] is open, spend some time next
week brainstorming

 Weekly Updates & Questions for the QA Team (hggdh) 
  * hggdh: we will be dropping regression-potential

 Weekly Updates & Questions for the Kernel Team (jjohansen) 
  * jjohansen: ill, not at meeting

 Weekly Updates & Questions for the Documentation Team (sommer) 
  * sommer: not around

 Weekly Updates & Questions for the Ubuntu Community Team (kim0) 
  * kim0: not around

 Open Discussion 
  * SRU 649591 (mountall spins eating cpu when 'nobootwait' option
exists in fstab followed by a comma)
   * kirkland sponsored smoser's proposal
  * ACTION:  Everyone to celebrate the 10.10.10 release in their own unique ways

 Announce next meeting date and time 
  * Tuesday 2010-10-12 at 1800 UTC - #ubuntu-meeting

-- 
:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Default use of caching on raw volumes

[Dustin Kirkland]

Serge E. Hallyn  wrote:
> Quoting Nikolai K. Bochev (n.boc...@grandstarco.com):
>> Now the question is - did the ubuntu team do some testing with this ?
>
> I don't know about Dustin.  I myself haven't really played with the
> caching options.

I have, only a bit though.  Mostly to make an informed default in the
TestDrive wrapper for KVM.

I tested and verified this part of the kvm(1) manpage:
 * http://manpages.ubuntu.com/kvm

   Some block drivers perform badly with cache=writethrough, most
   notably, qcow2.  If performance is more important than correctness,
   cache=writeback should be used with qcow2.

For TestDrive, "performance" is more important than "correctness"
since most TestDrive VMs are just throwaway VMs, and all use qcow2.

I have not conducted any deeper analysis, though.  Sorry.

:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: landscape-common

[Dustin Kirkland]

On Wed, Sep 1, 2010 at 12:32 PM, Nikolai K. Bochev
 wrote:
> Not sure if this is the right place to ask, so i'll just ask and duck.
> Since one of the last updates of landscape there was a change that
> disallowed displaying of motd stats if the loadavg is above 1.
> I could understand this for a desktop, but since the motd is displayed only
> on servers it makes no sense. I can hardly see people running servers ( even
> home use ) on single-core cpus.
> For example if i have 16 cores, it would make sense to disable it when i
> have loadavg > 16 ?
> Any other thoughts on that ?

I noticed the same thing, and yes, I agree that that test should scale
linearly with the number of CPUs in the system.  ie, the just need to
normalize the load divided by the number of cores.

I suggest that you file a bug against the package.  This is might even
be a papercuts candidate.

:-Dusitn

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: KSM Control Scripts

[Dustin Kirkland]

After changing that variable, you have to:
 sudo service qemu-kvm restart

Also, move it up by orders of 10.  Go from 20 to 200 to 2000.

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: KSM Control Scripts

[Dustin Kirkland]

Serge E. Hallyn  wrote:
> Quoting Nikolai K. Bochev (n.boc...@grandstarco.com):
>> I've stumbled upon those on the Proxmox VE forums, and as far as i can see 
>> they're in Fedora12 by default too.
>> http://gitorious.org/ksm-control-scripts
>> http://download.proxmox.com/sources/
>>
>>
>> Has anyone tested those on 10.04 KVM Host ?
>
> Not I
>
>> Any reason why they aren't included in Lucid ?
>
> Well, there is some talk out there (no links handy) about KSM being
> a performance hog anyway, and some people seem to turn it off.
>
>> I'll be giving those a shot next few days, will see how it goes.
>
> That'd be great, thanks in advance.  In particular, if you get some
> statistics about performance with various settings vs. # VMS vs mem
> vs cpu overhead, that'd be very useful.

Further to this

 1. KSM is enabled and running by default in Ubuntu 10.04
 2. The default polling scan frequency is left at the (perhaps
egregious) upstream Linux kernel default of 20ms.
 3. As Serge mentions, several people have complained about that being
to frequent.  Other people have complained about higher values being
not frequent enough to be useful
 4. In any case, this is totally and trivially configurable in your
/etc/default/qemu-kvm file.  Edit that to your heart's content and
then 'sudo restart qemu-kvm'.

Cheers,
:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Official Ubuntu Server Book (Issue 2)

[Dustin Kirkland]

On Sun, Aug 15, 2010 at 12:45 PM, Kyle Rankin
 wrote:
> On Sun, Aug 15, 2010 at 04:35:21PM +0100, Mark Fraser wrote:
>> Does anyone know when the above book - which was supposed to have been
>> released on the 8th August - is likely to be released?
>>
>> --
>> Registered Linux User #466407 http://counter.li.org
>
> I just received my first author copy so presumably they should be on their
> way to bookstores now. I'm not aware of any delays.

With the purple cover?  If so, I saw a stack of them at LinuxCon in
Boston last week...

:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Ubuntu server and cloud IRC consolidation

[Dustin Kirkland]

On Thu, Aug 12, 2010 at 11:36 AM, Scott Kitterman  wrote:
> On Thursday, August 12, 2010 11:19:05 am Dustin Kirkland wrote:
>> On Thu, Aug 12, 2010 at 11:13 AM, Scott Kitterman 
> wrote:
>> > On Wednesday, August 11, 2010 11:02:05 pm Dustin Kirkland wrote:
>> >> On Wed, Aug 11, 2010 at 4:49 PM, Scott Kitterman 
>> >
>> > wrote:
>> >> > On Wednesday, August 11, 2010 04:21:36 pm Dustin Kirkland wrote:
>> >> >> On Wed, Aug 11, 2010 at 11:35 AM, Scott Kitterman
>> >> >> 
>> >> >
>> >> > wrote:
>> >> >> > On Wednesday, August 11, 2010 11:28:28 am Mathias Gug wrote:
>> >> >> >> Hi,
>> >> >> >>
>> >> >> >> Excerpts from Dan Sheffner's message of Wed Aug 11 11:14:04 -0400
> 2010:
>> >> >> >> > I guess the only question I have is where do I ask questions
>> >> >> >> > about the KVM hypervisor, virsh, and vmbuilder commands?
>> >> >> >> > #ubuntu-server or #ubuntu-cloud? it would nice to have one room
>> >> >> >> > like #ubuntu-vm for virtual machines that would include xen,
>> >> >> >> > kvm, virsh, virtualbox, eucalyptus, etc.
>> >> >> >>
>> >> >> >> As outlined in the proposal:
>> >> >> >>
>> >> >> >>   1) Development discussion happens in #ubuntu-devel
>> >> >> >>      * e.g. packaging, patching, debugging, development, etc.
>> >> >> >>
>> >> >> >>   2) Traditional server discussion happens in #ubuntu-server
>> >> >> >>      * e.g. running Ubuntu on your server hardware or in a *
>> >> >> >> virtual machine, getting it installed, configuration/management
>> >> >> >> of services, virtualization, etc.
>> >> >> >>
>> >> >> >>   3) New-age cloud server discussion happens in #ubuntu-cloud
>> >> >> >>      * e.g. running UEC private clouds, running Ubuntu * in EC2,
>> >> >> >> cloud work loads, ensemble cloud magic, etc.
>> >> >> >>
>> >> >> >> #ubuntu-server seems the appropriate place to ask questions about
>> >> >> >> KVM, virsh and vmbuilder.
>> >> >> >
>> >> >> > I missed in the original proposal that development is now off topic
>> >> >> > in #ubuntu- server.  I object to this change.  #ubuntu-server has
>> >> >> > been a joint developer/user channel for a very long time now.
>> >> >> >  It's the one place in the Ubuntu project where users and
>> >> >> > developers are on the same channels (yes, some developers are on
>> >> >> > user channels, to help, but that's different).  We discussed this
>> >> >> > very change not very long ago and the consensus was not to change
>> >> >> > it.
>> >> >> >
>> >> >> > I feel like this change was slipped in with other changes about IRC
>> >> >> > channel consolidation and should have been (re) discussed
>> >> >> > separately (although honestly I don't see the need to revisit the
>> >> >> > discussion so soon).
>> >> >>
>> >> >> Scott,
>> >> >>
>> >> >> I don't think anything really changes in #ubuntu-server, from a
>> >> >> development discussion perspective.  There's plenty of
>> >> >> development-related conversations that will continue in
>> >> >> #ubuntu-server, perfectly on-topic.  No one is getting kicked/banned
>> >> >> from there, and no one should get slapped on the wrist for talking
>> >> >> devel (in my opinion).
>> >> >>
>> >> >> I read Ahmed's proposition to really be about consolidating
>> >> >> cloud/virt/ensemble/ec2 channels into one -- simplifying the
>> >> >> landscape for those of us subscribed to all 4 and unraveling the
>> >> >> maze for our users seeking cloud-related support.
>> >> >>
>> >> >> The previous recent discussion you refer to, I think, was about
>> >> >> splitting #ubuntu-server and #ubuntu-server-devel.  As I remember it,
>> >> >> we, as 

Re: Ubuntu server and cloud IRC consolidation

[Dustin Kirkland]

On Thu, Aug 12, 2010 at 11:13 AM, Scott Kitterman  wrote:
> On Wednesday, August 11, 2010 11:02:05 pm Dustin Kirkland wrote:
>> On Wed, Aug 11, 2010 at 4:49 PM, Scott Kitterman 
> wrote:
>> > On Wednesday, August 11, 2010 04:21:36 pm Dustin Kirkland wrote:
>> >> On Wed, Aug 11, 2010 at 11:35 AM, Scott Kitterman 
>> >
>> > wrote:
>> >> > On Wednesday, August 11, 2010 11:28:28 am Mathias Gug wrote:
>> >> >> Hi,
>> >> >>
>> >> >> Excerpts from Dan Sheffner's message of Wed Aug 11 11:14:04 -0400 2010:
>> >> >> > I guess the only question I have is where do I ask questions about
>> >> >> > the KVM hypervisor, virsh, and vmbuilder commands? #ubuntu-server
>> >> >> > or #ubuntu-cloud? it would nice to have one room like #ubuntu-vm
>> >> >> >  for virtual machines that would include xen, kvm, virsh,
>> >> >> > virtualbox, eucalyptus, etc.
>> >> >>
>> >> >> As outlined in the proposal:
>> >> >>
>> >> >>   1) Development discussion happens in #ubuntu-devel
>> >> >>      * e.g. packaging, patching, debugging, development, etc.
>> >> >>
>> >> >>   2) Traditional server discussion happens in #ubuntu-server
>> >> >>      * e.g. running Ubuntu on your server hardware or in a * virtual
>> >> >>        machine, getting it installed, configuration/management of
>> >> >>        services, virtualization, etc.
>> >> >>
>> >> >>   3) New-age cloud server discussion happens in #ubuntu-cloud
>> >> >>      * e.g. running UEC private clouds, running Ubuntu * in EC2,
>> >> >> cloud work loads, ensemble cloud magic, etc.
>> >> >>
>> >> >> #ubuntu-server seems the appropriate place to ask questions about
>> >> >> KVM, virsh and vmbuilder.
>> >> >
>> >> > I missed in the original proposal that development is now off topic in
>> >> > #ubuntu- server.  I object to this change.  #ubuntu-server has been a
>> >> > joint developer/user channel for a very long time now.  It's the one
>> >> > place in the Ubuntu project where users and developers are on the same
>> >> > channels (yes, some developers are on user channels, to help, but
>> >> > that's different).  We discussed this very change not very long ago
>> >> > and the consensus was not to change it.
>> >> >
>> >> > I feel like this change was slipped in with other changes about IRC
>> >> > channel consolidation and should have been (re) discussed separately
>> >> > (although honestly I don't see the need to revisit the discussion so
>> >> > soon).
>> >>
>> >> Scott,
>> >>
>> >> I don't think anything really changes in #ubuntu-server, from a
>> >> development discussion perspective.  There's plenty of
>> >> development-related conversations that will continue in
>> >> #ubuntu-server, perfectly on-topic.  No one is getting kicked/banned
>> >> from there, and no one should get slapped on the wrist for talking
>> >> devel (in my opinion).
>> >>
>> >> I read Ahmed's proposition to really be about consolidating
>> >> cloud/virt/ensemble/ec2 channels into one -- simplifying the landscape
>> >> for those of us subscribed to all 4 and unraveling the maze for our
>> >> users seeking cloud-related support.
>> >>
>> >> The previous recent discussion you refer to, I think, was about
>> >> splitting #ubuntu-server and #ubuntu-server-devel.  As I remember it,
>> >> we, as a community, n'acked the creation/separation to
>> >> #ubuntu-server-devel, as we didn't want to divorce ourselves from our
>> >> user support channel.  I still agree with that sentiment, and I think
>> >> that's unchanged even in Ahmed's IRC realignment suggestion.
>> >
>> > Then I'm a little unclear what Mathiaz' point #1 is about then.
>> >  "Development discussion happens in #ubuntu-devel" seems pretty clear to
>> > me.
>>
>> I think it's pretty clear, and 100% true.  Development discussion
>> does, in fact, happen in #ubuntu-devel.
>>
>> I haven't seen anything forbidding development discussion happenin

Re: Ubuntu server and cloud IRC consolidation

[Dustin Kirkland]

On Wed, Aug 11, 2010 at 4:49 PM, Scott Kitterman  wrote:
> On Wednesday, August 11, 2010 04:21:36 pm Dustin Kirkland wrote:
>> On Wed, Aug 11, 2010 at 11:35 AM, Scott Kitterman 
> wrote:
>> > On Wednesday, August 11, 2010 11:28:28 am Mathias Gug wrote:
>> >> Hi,
>> >>
>> >> Excerpts from Dan Sheffner's message of Wed Aug 11 11:14:04 -0400 2010:
>> >> > I guess the only question I have is where do I ask questions about the
>> >> > KVM hypervisor, virsh, and vmbuilder commands? #ubuntu-server or
>> >> > #ubuntu-cloud? it would nice to have one room like #ubuntu-vm  for
>> >> > virtual machines that would include xen, kvm, virsh, virtualbox,
>> >> > eucalyptus, etc.
>> >>
>> >> As outlined in the proposal:
>> >>
>> >>   1) Development discussion happens in #ubuntu-devel
>> >>      * e.g. packaging, patching, debugging, development, etc.
>> >>
>> >>   2) Traditional server discussion happens in #ubuntu-server
>> >>      * e.g. running Ubuntu on your server hardware or in a * virtual
>> >>        machine, getting it installed, configuration/management of
>> >>        services, virtualization, etc.
>> >>
>> >>   3) New-age cloud server discussion happens in #ubuntu-cloud
>> >>      * e.g. running UEC private clouds, running Ubuntu * in EC2, cloud
>> >>        work loads, ensemble cloud magic, etc.
>> >>
>> >> #ubuntu-server seems the appropriate place to ask questions about KVM,
>> >> virsh and vmbuilder.
>> >
>> > I missed in the original proposal that development is now off topic in
>> > #ubuntu- server.  I object to this change.  #ubuntu-server has been a
>> > joint developer/user channel for a very long time now.  It's the one
>> > place in the Ubuntu project where users and developers are on the same
>> > channels (yes, some developers are on user channels, to help, but that's
>> > different).  We discussed this very change not very long ago and the
>> > consensus was not to change it.
>> >
>> > I feel like this change was slipped in with other changes about IRC
>> > channel consolidation and should have been (re) discussed separately
>> > (although honestly I don't see the need to revisit the discussion so
>> > soon).
>>
>> Scott,
>>
>> I don't think anything really changes in #ubuntu-server, from a
>> development discussion perspective.  There's plenty of
>> development-related conversations that will continue in
>> #ubuntu-server, perfectly on-topic.  No one is getting kicked/banned
>> from there, and no one should get slapped on the wrist for talking
>> devel (in my opinion).
>>
>> I read Ahmed's proposition to really be about consolidating
>> cloud/virt/ensemble/ec2 channels into one -- simplifying the landscape
>> for those of us subscribed to all 4 and unraveling the maze for our
>> users seeking cloud-related support.
>>
>> The previous recent discussion you refer to, I think, was about
>> splitting #ubuntu-server and #ubuntu-server-devel.  As I remember it,
>> we, as a community, n'acked the creation/separation to
>> #ubuntu-server-devel, as we didn't want to divorce ourselves from our
>> user support channel.  I still agree with that sentiment, and I think
>> that's unchanged even in Ahmed's IRC realignment suggestion.
>
> Then I'm a little unclear what Mathiaz' point #1 is about then.  "Development
> discussion happens in #ubuntu-devel" seems pretty clear to me.

I think it's pretty clear, and 100% true.  Development discussion
does, in fact, happen in #ubuntu-devel.

I haven't seen anything forbidding development discussion happening in
#ubuntu-server.

Have you gotten that impression?  Does the above policy deserve some
clarification?  Perhaps that "general" Ubuntu development discussion
should land in #ubuntu-devel, while Server-specific development
discussion is encouraged (or belongs) in #ubuntu-server.  That's just
status quo, as far as I'm concerned, though.

:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Ubuntu server and cloud IRC consolidation

[Dustin Kirkland]

On Wed, Aug 11, 2010 at 11:35 AM, Scott Kitterman  wrote:
> On Wednesday, August 11, 2010 11:28:28 am Mathias Gug wrote:
>> Hi,
>>
>> Excerpts from Dan Sheffner's message of Wed Aug 11 11:14:04 -0400 2010:
>> > I guess the only question I have is where do I ask questions about the
>> > KVM hypervisor, virsh, and vmbuilder commands? #ubuntu-server or
>> > #ubuntu-cloud? it would nice to have one room like #ubuntu-vm  for
>> > virtual machines that would include xen, kvm, virsh, virtualbox,
>> > eucalyptus, etc.
>>
>> As outlined in the proposal:
>>
>>   1) Development discussion happens in #ubuntu-devel
>>      * e.g. packaging, patching, debugging, development, etc.
>>
>>   2) Traditional server discussion happens in #ubuntu-server
>>      * e.g. running Ubuntu on your server hardware or in a * virtual
>>        machine, getting it installed, configuration/management of
>>        services, virtualization, etc.
>>
>>   3) New-age cloud server discussion happens in #ubuntu-cloud
>>      * e.g. running UEC private clouds, running Ubuntu * in EC2, cloud
>>        work loads, ensemble cloud magic, etc.
>>
>> #ubuntu-server seems the appropriate place to ask questions about KVM,
>> virsh and vmbuilder.
>
> I missed in the original proposal that development is now off topic in 
> #ubuntu-
> server.  I object to this change.  #ubuntu-server has been a joint
> developer/user channel for a very long time now.  It's the one place in the
> Ubuntu project where users and developers are on the same channels (yes, some
> developers are on user channels, to help, but that's different).  We discussed
> this very change not very long ago and the consensus was not to change it.
>
> I feel like this change was slipped in with other changes about IRC channel
> consolidation and should have been (re) discussed separately (although
> honestly I don't see the need to revisit the discussion so soon).

Scott,

I don't think anything really changes in #ubuntu-server, from a
development discussion perspective.  There's plenty of
development-related conversations that will continue in
#ubuntu-server, perfectly on-topic.  No one is getting kicked/banned
from there, and no one should get slapped on the wrist for talking
devel (in my opinion).

I read Ahmed's proposition to really be about consolidating
cloud/virt/ensemble/ec2 channels into one -- simplifying the landscape
for those of us subscribed to all 4 and unraveling the maze for our
users seeking cloud-related support.

The previous recent discussion you refer to, I think, was about
splitting #ubuntu-server and #ubuntu-server-devel.  As I remember it,
we, as a community, n'acked the creation/separation to
#ubuntu-server-devel, as we didn't want to divorce ourselves from our
user support channel.  I still agree with that sentiment, and I think
that's unchanged even in Ahmed's IRC realignment suggestion.

Cheers,
:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Ubuntu server and cloud IRC consolidation

[Dustin Kirkland]

Clint Byrum  wrote:
> On Aug 9, 2010, at 7:59 AM, Ahmed Kamal wrote:
>> I suggest that #Ubuntu-virt be closed, and all traffic and new joines
>> force-redirected to #ubuntu-server.
>>
>> Similarly, that #Ubuntu-ec2 and #Ubuntu-ensemble be closed and all
>> traffic and new joins force-redirected to #ubuntu-cloud.
>>
>
> Agreed with all except #ubuntu-ensemble.
>
> I think its still a bit early in its development to consolidate into a 
> channel that is focused on the support and discussion of the mature Ubuntu 
> platform.

I disagree.

I think the Ubuntu Ensemble project would greatly benefit from
exposure and discussion within #ubuntu-cloud.  Having lingered in
#ubuntu-ensemble for a few months now, I think most discussions in
there that would benefit the greater Ubuntu cloud/virt/ec2 community.

:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Ubuntu server and cloud IRC consolidation

[Dustin Kirkland]

On Mon, Aug 9, 2010 at 10:59 AM, Ahmed Kamal  wrote:
> I've been thinking about ways to grow the Ubuntu server and cloud
> communities. As it stands, I think there is a bit of fragmentation in
> the server and cloud related IRC channels. Since active and
> knowledgeable IRC community members are a valuable resource, I think it
> is beneficial to consolidate channels. Here's what I think could help
>
> I suggest that #Ubuntu-virt be closed, and all traffic and new joines
> force-redirected to #ubuntu-server.
>
> Similarly, that #Ubuntu-ec2 and #Ubuntu-ensemble be closed and all
> traffic and new joins force-redirected to #ubuntu-cloud.
>
> Thus:
>
>  1) Development discussion happens in #ubuntu-devel
>     * e.g. packaging, patching, debugging, development, etc.
>
>  2) Traditional server discussion happens in #ubuntu-server
>     * e.g. running Ubuntu on your server hardware or in a virtual
> machine, getting it installed, configuration/management of services,
> virtualization, etc.
>
>  3) New-age cloud server discussion happens in #ubuntu-cloud
>     * e.g. running UEC private clouds, running Ubuntu in EC2, cloud
> work loads, ensemble cloud magic, etc.
>
> When someone /join #ubuntu-ec2, they're plopped right into #ubuntu-cloud
> (and the same for the other consolidated channels).
>
> Would love to hear your feedback

Complete +1 from me on this proposal.

I think the 3-way split makes perfect sense (devel, traditional
servers, cloud) to me.  It greatly simplifies our communication, and
reduces the excessive separation of discussion.

How soon can we make this happen?  :-)

:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Ubuntu Server Team Meeting Minutes from 2010-07-27

[Dustin Kirkland]

See https://wiki.ubuntu.com/MeetingLogs/Server/20100727 for full log
and full text markup.  Cross-posted here because I'm required to do
so.  But seriously, give your eyes a break and go read them from the
wiki instead :-)

Minutes

Action Points Review with kirkland
hggdh to discuss the outcome of server-maverick-qa-workflow in
ServerMeeting during the beta cycle
sommer/smoser in sync on cloud-init documentation, action DONE
[ACTION] SpamapS to work with mathiaz on a proposal, and send proposal
to -devel on ruby gems in ubuntu

Maverick Developments with jiboumans
we are a bit behind on Alpha3; somewhat expected; only low priority
specs affected so far

QA Q&A with hggdh
hggdh has filed a few (4) bugs against eucalyptus-2.0

Kernel Chit Chat with jjohansen
jjohansen has a pv-ops kernel in testing; apparmor fixes queued and
should be uploaded; lucid high load average bug may not be an illusion


Doc Talk with sommer
uec section updated from the wiki docs in
http://doc.ubuntu.com/ubuntu/serverguide/C/uec.html
[ACTION] Daviey & kirkland to review
http://doc.ubuntu.com/ubuntu/serverguide/C/uec.html

SRU Fun with zul
10.04.1 is coming up; need to know about SRU bugs ASAP

Bloody Papercuts with ttx
not in good shape; papercuts need to be fixed by end of the week to make Alpha3
[ACTION] entire team to fix your papercuts by end-of-the-week

Triage Backlog with ttx
regular triage work slipped last week; likely culprits: pilsner and
absynthe; everyone to help out clearing the queue

Open Discussion
kim0 to deploy a web app that will let people show where in the world
they are running an Ubuntu server
roaksoax says that we should have an HA cluster in Main for Maverick
[ACTION] SpamapS and ScottK to reivew Kolab php5 patches

Next meeting will be on Tuesday, April 14th at 15:00 UTC in #ubuntu-meeting.

:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Changing the font size on the server screen

[Dustin Kirkland]

On Thu, Jun 3, 2010 at 3:58 PM, Abadie Pablo  wrote:
> I need to know if there is a way to change the font size in the server 10.04 
> version. I´m using a big lcd monitor and it is difficult to use for my visual 
> problems.

sudo dpkg-reconfigure console-setup

Click through a bunch of questions in there, and one of the last ones
will be about the console font size.

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: S3 sleep with ubuntu-server

[Dustin Kirkland]

On Wed, May 5, 2010 at 1:22 PM, Sasha Levin  wrote:
> I'm testing S3 sleep on a server installed with ubuntu-server.

Awesome!  I use it *all* the time with the 10+ machines I use in my
house running Ubuntu server.  It saves me many dollars per month, when
these machines are idle.

> Sending it to sleep and waking it up once using wake-on-lan once works well.
> Further attempts to send it to sleep make it resume from sleep almost
> instantaneously without any obvious reason.

Please file a bug against the pm-utils package in Ubuntu.  Please
explain a bit more there about what the effect is, what hardware you
have, etc.

> I've tried running the same test using ubuntu-desktop, but that worked
> perfectly. The server stayed in S3 even after several wake-on-lan cycles.
> /var/log/syslog and /var/log/messages don't show a clear reason why the
> desktop works and the server doesn't

What are you using to suspend both?  /usr/sbin/pm-suspend?

Can you wake it correctly with other mechanisms besides WoL?  Like
just pressing the power button?  If so, then it's probably breakage in
the ethernet driver, and may be work-around-able (sp?) with ethtool.

:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Server Team 20100414 meeting minutes

[Dustin Kirkland]

Ubuntu Server Team weekly minutes have been published at:
 * https://wiki.ubuntu.com/MeetingLogs/Server/20100428

Summary:
On track for Lucid release.  Get Blueprints filed for Maverick UDS as
soon as possible!

Actions:
 1. hggdh, zul to get their release note/early SRU bugs known to ttx
 2. ALL to mark DONE or POSTPONED the remaining work items for 10.04
by Thu 29 April EOD
 3. hggdh to outline testing bottlenecks for UEC testing UDS session

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Lucid Root on RAID1

[Dustin Kirkland]

On Mon, Apr 26, 2010 at 8:50 AM, Imre Gergely  wrote:
> I've tried various things but couldn't reproduce the problem... See my
> comments in the bugreport.

Thanks, Imre.

Please, anyone else looking at this, comment in the bug report:
 * https://bugs.edge.launchpad.net/ubuntu/+source/mdadm/+bug/569900

At this point, it appears to be related to the geometry of the disks.
Still investigating.

-- 
:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Lucid Root on RAID1

[Dustin Kirkland]

Howdy-

All of the testing I've done on Lucid/RAID1 at the milestones has been
within KVM, using file-backed disk images, which continues to work
well.  While this is a convenient test scenario, obviously it doesn't
match "real life".

This weekend, I reinstalled my primary server at home with Lucid and
tried to put / on a RAID1.  I struggled mightily with this, eventually
filing https://bugs.edge.launchpad.net/ubuntu/+source/mdadm/+bug/569900.

I run into a number of problems, beginning with my reboot landing me
in (initramfs) shell, and unable to mount /dev/md0 (though it exists,
and is syncing).

I'm wondering if anyone else in the Ubuntu Server community can help
confirm or deny this bug.  You would need to have real hardware with
two disks, that you can reinstall.  Please post your results here, if
you can help test this.

Thanks!

-- 
:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

[RFC] meeting minutes

[Dustin Kirkland]

Howdy team-

I propose that we adjust the way we collect and publish meeting minutes,
preserving their usefulness while reducing the time required of the
weekly scribe.

Specifically, section "8.0.3.2. Publishing the minutes" of
https://wiki.ubuntu.com/ServerTeam/KnowledgeBase .

Steps 1a-1c are fine.  But step 1d can take a very long time.  It takes me
at least 1 hour to write the minutes for a 1 hour meeting.  I've
confirmed that it takes Thierry about the same as well.

I suggest refining this step to consist of the following two simple
processes:
  i) Extract the ACTION items to a section near the top of the
MeetingLog page listing all ACTIONs
  ii) When pasting the full log into the {{{ }}} section, quickly scan
the log and indent the line or lines where "important things were said"
or "decisions were made".  (Ideally, we would bold the text or
something, but the {{{ }}} tags say "render this literally)

I believe that these two key points will maintain the usefulness of the
minutes, by tracking the actions that should be carried over from
meeting to meeting and highlighting the key points in the meeting.  This
should probably consume less than 10 minutes of time.

As for step 2, Publishing the minutes, personally I do not see the value
in duplicating the text in 4 locations:
 * the ubuntu-server@ list
 * the ubuntu-devel@ list
 * the ubuntuserver blog
 * the wiki MeetingLogs

I think that the minutes should be published in the MeetingLogs wiki,
and a hyperlink shared on the two mailing list and the blog.

Alternatively, I came across this:
 * https://wiki.ubuntu.com/ScribesTeam/SubmitMeeting

Looks like there's an active team in the Ubuntu Community that processes
the output of MootBot and generates minutes.  What do we think about
enlisting their services?

Comments?  Can we please reduce the scribe burden a bit?

-- 
:-Dustin

Dustin Kirkland
Canonical, LTD
kirkl...@canonical.com
GPG: 1024D/83A61194



signature.asc
Description: This is a digitally signed message part
-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: mdadm 2.6.7.1-1ubuntu15 -> 3.0.3

[Dustin Kirkland]

On Tue, Apr 13, 2010 at 8:51 AM, Andrew Dunn
 wrote:
> Is there a system for someone to make a propositon of request for a package
> upgrade?

https://wiki.ubuntu.com/SyncRequestProcess
https://wiki.ubuntu.com/MOTU/School/Merging-and-Syncing

> I would be interested in nominating that mdadm be moved to the next major
> revision before lucid's release.

Thanks for the feedback.  The above links show how to go about making
such a request.

Having merged mdadm before in the past, I can say that chances are
slim that someone will be able to merge mdadm and test it sufficiently
before Lucid's release.  The diff is rather large, and definitely
non-trivial.  Also, since the version is changing from 2.6.7 to 3.0.3,
presumably there are major architectural changes and new features.
Since we're beyond FeatureFreeze, this merge would have to go through
the FF process.

I suspect this request is far more likely to be acceptable for Maverick.

Thanks,
:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: kqemu and Ubuntu

[Dustin Kirkland]

2010/4/13 Ante Karamatić :
> OK. So kqemu was dropped, that's fine. But what about systems that don't
> have VT-enabled hardware but would still like to use vmbuilder?
>
> In 8.04 it was possible to use 'ubuntu-vm-builder qemu hardy', but now
> only (forgetting about vmware and xen for a moment) 'vmbuilder kvm
> hardy' works. Without kvm module initialized, this operation fails. I'd
> like to have virtualized systems inside of already virtualized system
> (therefor, no hardware acceleration). Errors:
>
> libvir: Domain Config error : internal error no supported architecture
> for os type 'hvm'
>
> libvirt.libvirtError: internal error no supported architecture for os
> type 'hvm'
>
> Basically, vmbuilder does the whole work, but dies on XML generation (if
> you use --debug, you actually get to see generated xml). And if XML is
> created by hand, libvirt starts it with command:
>
> LC_ALL=C
> PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin
> QEMU_AUDIO_DRV=none /usr/bin/qemu -S -M pc-0.12 -no-kvm -m 512 -smp 1
> -name test -uuid 7d78cbee-3832-ca61-ffdb-d3ec63c8db19 -chardev
> socket,id=monitor,path=/var/lib/libvirt/qemu/test.monitor,server,nowait
> -monitor chardev:monitor -no-acpi -boot c -drive
> file=/home/ivoks/VM/test/tmpkP59W4.qcow2,if=ide,index=0,boot=on -net
> none -serial none -parallel none -usb -vnc 192.168.79.2:0 -vga cirrus
>
> And this fails (system never loads grub completely). But if 'boot=on'
> (in drive setup) is removed or replaced with 'boot=off' and then started
> by hand, everything works fine.
>
> Is all of this on purpose or is it a bug (or bugs)?

Sounds like a bug...

The kvm binary should currently fall back to running without
acceleration, if no acceleration is available.

kirkl...@x200:/local/virt/iso$ sudo stop qemu-kvm
[sudo] password for kirkland:
qemu-kvm stop/waiting
kirkl...@x200:/local/virt/iso$ time kvm -m 512 -cdrom lucid-desktop-amd64.iso
open /dev/kvm: No such file or directory
Could not initialize KVM, will disable KVM support

I should think that vmbuilder should be able to continue using qemu
(or kvm) in a non-accelerated manner.  I just booted a LiveCD without
KVM.  It worked, though it took a long time to boot (~10 minutes).

:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

kqemu and Ubuntu

[Dustin Kirkland]

This message is directed at users of Virtualization in Ubuntu, and
specifically those who use kqemu in versions of Ubuntu <= 9.04.

You may safely disregard this message if:
 * you do not care about Virtualization in Ubuntu (kqemu, qemu, kvm), or
 * you're already happily running Ubuntu 9.10, or Ubuntu 10.04 LTS, or
 * you are not using kqemu at all (see: dpkg -l kqemu*)

As discussed at UDS-Lucid in November last year, upstream QEMU has
completely dropped support for kqemu, and consequently will not be
available in Ubuntu 10.04 LTS.  The decision has been discussed at
length in several bug reports, mailing list posts, and in IRC.  I have
compiled a set of FAQs here, to help address the recurring questions:
 * http://blog.dustinkirkland.com/2010/04/kqemu-and-ubuntu.html
 * https://help.ubuntu.com/community/Kqemu

My apologies for the cross-posting.  The Ubuntu Server Team is simply
trying to pro-actively notify users of Ubuntu users of kqemu ahead of
the 10.04 LTS release, and direct users with recurring questions to
the FAQ pages on the topic.

Thanks,
:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: libvirt 0.7.7 and Lucid

[Dustin Kirkland]

Per conversation in IRC [1], I'm recommending that we stick with
libvirt 0.7.5 for Lucid, due to the incompatibility it introduces with
hotplug of scsi disks (and the resulting regression it introduces in
UEC/Eucalyptus for EBS volumes).

[1] http://irclogs.ubuntu.com/2010/04/02/%23ubuntu-server.html#t15:33

Maverick will certainly introduce >= libvirt 0.7.7, which will force
us to move to virtio disks for UEC/Eucalyptus (which will introduce a
nice performance bump, and possibly a stability enhancement, but most
importantly align us with upstream's recommended way of adding disks),
and we'll have an entire release cycle to work our way through any
issues that arise (rather than a mere 2 hectic weeks).

Tremendous thanks to you, Jamie, for all the work you've done on
Libvirt, helping the Ubuntu Server team out immensely in the Karmic
and Lucid cycles!!!

Cheers,
:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: libvirt 0.7.7 and Lucid

[Dustin Kirkland]

On Thu, Apr 1, 2010 at 12:01 PM, Scott Moser  wrote:
> On Wed, 31 Mar 2010, Dustin Kirkland wrote:
>> On Thu, Mar 25, 2010 at 1:09 PM, Jamie Strandboge  
>> wrote:
>> > 3. libvirt seems to try to guard against hypervisor issues regarding
>> > detach-device and detach-disk. Specifically, these can be hot-plugged,
>> > but not hot-unplugged (libvirt claims the qemu-kvm hypervisor doesn't
>> > support detach of these):
>> >    
>> >      
>> >      
>> >      
>> >      
>> >      
>> >    
>
> hotplug attach and detach of scsi driver disks is an absolute requirement
> for UEC with Eucalyptus 1.6.2.  It is the basis of the "EBS" (Elastic
> Block Store) functionality (euca-attach-volume, euca-detach-volume).

Jamie and I spent a good bit of today testing libvirt 0.7.7, in
particular against Lucid UEC.

The basic tests from Mathias' lp:~mathiaz/%2Bjunk/uec-testing-scripts
all ran just fine, as well as my basic tests of virsh, and
virt-manager.

The package build also runs the upstream test suite, all test of which pass:
 * 
http://launchpadlibrarian.net/42047543/buildlog_ubuntu-lucid-amd64.libvirt_0.7.7-4ubuntu1~jdstrand2_FULLYBUILT.txt.gz

However, hot add of scsi disks (as used by Eucalyptus's EBS
implementation) did not work, unfortunately.  Note that we used these
instructions from Scott to test:
 * http://paste.ubuntu.com/407717/

After a conversation with upstream in #virt in IRC, Jamie filed the
upstream bug:
 * https://bugzilla.redhat.com/show_bug.cgi?id=578975

We think that we've identified the problematic commit (but this
doesn't unapply cleanly).  See:
264e98d6a85bb467f364006c1dac3993688691ce [PATCH] Make hotplug use new
device_add where possible

Libvirt needs to go back to using pci_add for scsi hot attach of disks.

Jamie and I are in agreement that this regression is a blocker for
uploading 0.7.7.

We also defined the functional acceptance criteria for 0.7.7 upload to
be (assuming we can get this fixed):
 * the upstream QA tests all pass
 * the security regression tests all pass
 * Mathias' UEC tests all pass
 * and Dan's S3/EBS tests all pass

:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: qemu-kvm vde networking [was Re: Sorry to bother you]

[Dustin Kirkland]

On Wed, Mar 31, 2010 at 7:41 AM, Dustin Kirkland  wrote:
>  1) A qemu-kvm package in a PPA managed by ~ubuntu-virt in Launchpad
> that does build against libvdeplug2-dev
>  * We can try to keep this package "in sync" with what goes into Lucid
> (ie, upload at the same time and just enable vde in the PPA build)
>  * But any problems or issues caused by or related to VDE will be
> supported on a best-effort, wishlist-priority basis (as are most PPA
> builds)

FYI, I have uploaded such a package to:
 * https://launchpad.net/~ubuntu-virt/+archive/vde

I'll try to keep this package up-to-date with whatever goes into
10.04, but as stated above, it's minimally-supported.

If you're happy with VDE networking as is, you're welcome to use this PPA.

Cheers,
:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: libvirt 0.7.7 and Lucid

[Dustin Kirkland]

Sorry for my delayed response.  I have had IRC conversations with
Jamie, Thierry, and others about this, but I felt that I should roll
that up and respond inline below for the sake of posterity and
accuracy of the Wayback Machine years from now ;-)

On Thu, Mar 25, 2010 at 1:09 PM, Jamie Strandboge  wrote:
> Hi,
>
> For some work[1] I am doing, I did a merge of 0.7.7-4 from Debian
> unstable for Lucid and made it available in my PPA[2] (though it hasn't
> built yet-- people can grab the source and build it locally if desired).
> This package may be worth considering for Lucid, since there are many
> bug fixes and few new features in 0.7.6 and 0.7.7[3] (Lucid currently
> has 0.7.5).

Thanks, Jamie, for your sustained work on libvirt.  Your help is much
appreciated by the Ubuntu Server Team ;-)

> My testing with QRT[4], manually and the internal test suite (enabled by
> default in the build) shows that 0.7.7 is quite solid, though it does a
> couple of things differently:

Gotta love knowing that there's an upstream test suite ;-)

> 1. the setmem, setmaxmem and setvcpus virsh commands are for hotplugging
> memory and vcpus only. This was always the intent of these commands, but
> libvirt did not enforce it. Now it does and qemu-kvm doesn't seem to
> support hotplugging of memory and vcpus (at least with how libvirt
> interfaces with it). In practice, this probably won't affect many users
> as the recommended method has always been to use 'virsh define' and
> restart the guest. virt-manager appears to use 'virsh define' for
> setmaxmem, I don't know how eucalyptus deals with this.

I'm pretty sure that Eucalyptus does not use memory or CPU hotplug.  I
have CC'd Dan Nurmi on this note to definitely confirm.  Dan- every
Eucalyptus instance is started anew from a fresh libvirt xml file,
with mem/cpu/disk specified by the user's selection of machine-type,
correct?  And there's no hotplug of memory or cpu to running
Eucalyptus instances, right?

> 2. upstream decided to make setmaxmem go away entirely, and 0.7.7's
> implementation of setmaxmem is in the middle of this transition and
> doesn't seem to work at all. 'virsh define' still does though. I'm also
> not sure if this is a bug or new design, but while you can define a VM
> with different  and , when you start the VM,
>  is always allocated for the VM and  is ignored.

Interesting.  I can't exactly say what this will affect.  Does the new
Virt-Manager handle this by disabling the prompt for both memory and
currentMemory?  This has been a source of confusion for Virt-Manager
users for some time now, so I think it would be good to simplify this,
if that's what they've done in Libvirt upstream.

> 3. libvirt seems to try to guard against hypervisor issues regarding
> detach-device and detach-disk. Specifically, these can be hot-plugged,
> but not hot-unplugged (libvirt claims the qemu-kvm hypervisor doesn't
> support detach of these):
>    
>      
>      
>      
>      
>      
>    
>
>    
>      
>      
>      
>      
>      
>    
>
> In 0.7.5, libvirt would try to detach these devices via the hypervisor,
> but in 0.7.7 it gives only a clear error message to the user. These QRT
> tests were built around upstream eucalyptus functionality, so this needs
> careful testing. Attaching and detaching virtio disks works fine in my
> testing.

Uh, oh...  Okay, this might be the big-nasty.  Eucalyptus does use
scsi hotplug for attaching EBS volumes.  Not sure about detach...
Dan, again can you advise us here?  Does Eucalyptus need to hot unplug
scsi disks from instances?

As for virtio, we're planning to file a blueprint for Lucid+1 and try
to get UEC using virtio for networking and disks.

> 4. libvirt chown's the disk files to root:root for people using
> qemu:///system. I don't know why it is doing this, but it is likely
> related to upstream changes (and assumptions) made for the DAC security
> driver. This seems like someone will need to at least investigate if not
> patch.

Hmm, okay, I think this is okay.  Looking at
/var/lib/eucalyptus/instances/admin/*/disk, these are owned by
root:root right now with libvirt 0.7.5-5ubuntu15 and eucalyptus
1.6.2-0ubuntu26, which is working.

> Beyond the above, preliminary testing indicates that 0.7.7 is quite
> solid. I would like to see this go into Lucid, since my apparmor work
> will be based on this and I'd rather not have to backport my work to
> 0.7.5. That said, I don't have the time to perform all the testing
> required, so if a commitment to testing resources can't be made for
> 0.7.7 by the server team and QA, then I recommend sticking with 0.7.5.

Right, so Jamie and I are going to spend most of Thursday this week,
dedicating time to testing libvirt 0.7.7, and specifically with UEC.

If we can quickly fix any regressions that we find, then I think it's
fine to upload libvirt 0.7.7 to Lucid.

However, if we encounter regressions with UEC and libvirt 0.7.7 which
are not quickly stomped, then I would probably r

qemu-kvm vde networking [was Re: Sorry to bother you]

[Dustin Kirkland]

On Wed, 2010-03-31 at 10:32 +0200, Christian Rößner wrote:
> excuse me please that I contact you directly. Before I go building my
> own kvm package with vde support I want to ask you, if you could give
> me detailed arguments, why vde is not in main repo and why you
> consider it not secure (enough; you said _more secure than_).
>
> I wait from release to release always missing the vde support and I
> can not understand why you do not include it. Where are the reasons?
> And why is vde not in main?
> 
> I have really good experiences with vde and kvm for years now. I use
> KVM for several minor internet service providers here in Germany and
> all the servers use vde, cause it is ingenious. 
> 
> Seperating local guest communication from outside. And!!!: You do not
> need bridging network, which makes firewalling so much easier. And you
> still can reach the host operating system from the guests, which gives
> you are real intranet.
> 
> So there are so many arguments FOR vde. Any other solution is really a
> pain. And I tested them all! I am not a newie.
> 
> So if security is an argument, then I would say ok.

Hi Christian, thanks for the kind, detailed email.  I hope you don't
mind that I'm CC'ing this response to the ubuntu-server@ and
ubuntu-devel@ mailing lists, as this has come up a few times, and I'd
like to collate a single response here...

Okay, let me eat my words on the security aspect of VDE...  I can't say
that VDE is more or less secure than the other recommended networking
models at:
 * https://help.ubuntu.com/community/KVM/Networking

What I can say is that:

 a) Per discussions with upstream QEMU, tap is the 'official',
'supported', 'recommended' networking mechanism for QEMU and KVM
  * Upstream also says that VDE performance is poor because it doesn't
support offloading, tap networking should suffice for vast majority of
users, VDE security is mostly untested for things like mac flooding and
ip spoofing, and upstream does virtually no testing of VDE before they
release

 b) The required library, libvdeplug2-dev and its source package, vde2
are in Ubuntu Universe, while qemu-kvm is in Ubuntu Main (Main packages
cannot build against libraries in Universe)

 c) Canonical-long-term-supported KVM in Ubuntu's Lucid Main repository
will not differ from Upstream's recommendation on this point

 d) The other networking models (ie, through KVM/Libvirt) are *far* more
heavily tested over the last 2 years of Ubuntu Hypervisor development,
through Hardy->Intrepid->Jaunty->Karmic->Lucid.

What we can offer is this:

 1) A qemu-kvm package in a PPA managed by ~ubuntu-virt in Launchpad
that does build against libvdeplug2-dev
  * We can try to keep this package "in sync" with what goes into Lucid
(ie, upload at the same time and just enable vde in the PPA build)
  * But any problems or issues caused by or related to VDE will be
supported on a best-effort, wishlist-priority basis (as are most PPA
builds)

 2) If someone who has interest in, and experience with VDE will write
the Main Inclusion Report (MIR) for vde2, we can propose vde2 for
inclusion in Main for Lucid+1, and I'll enable VDE in the qemu-kvm
builds for Lucid+1 if the MIR is approved.  See:
  * https://wiki.ubuntu.com/MainInclusionProcess
I have marked your bug a duplicate of another one, marked wont-fix
against Lucid, but marked it triaged/high for Lucid+1, at:
  * https://bugs.edge.launchpad.net/ubuntu/+source/vde2/+bug/253230

> But please include it. It is an LTS version, so big chance to make
> this pain an end ;-)

I understand your concern.  But this is the precise reason why we cannot
just enable VDE networking at this time.  We're at a Beta2 freeze for
our LTS release.  I appreciate your confidence in VDE -- that will
support the MIR process for Lucid+1.  But the vast majority of testing
and stabilization of Ubuntu's Hypervisor stack has been intensely
focused on the KVM+Libvirt networking model.  Slipping VDE networking
into Ubuntu 10.04 LTS at Beta2, and then committing to supporting that
code for 5 years is simply not something we can do, I'm sorry.

> As you read, I am from Germany. Sometimes my English may sound a
> little bit rough, but I do not mean it like this.

No problem ;-)

Cheers,
-- 
:-Dustin

Dustin Kirkland
Canonical, LTD
kirkl...@canonical.com
GPG: 1024D/83A61194


signature.asc
Description: This is a digitally signed message part
-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

2010-03-17 Meeting Minutes

[Dustin Kirkland]

2010-03-17 meeting minutes are posted at:
 * https://wiki.ubuntu.com/MeetingLogs/Server/20100317

The minutes have been up for two weeks, but the script that publishes
them here was broken, sorry.

-- 
:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: openssh-server and cman with only 3y support??

[Dustin Kirkland]

On Thu, Mar 25, 2010 at 8:52 AM, carlopmart  wrote:
>  Sorry but there are things I can not understand. Why openssh-server package 
> only
> has 3y support in lucid server edition?? IMHO openssh-server is a very very
> important tool to administrate a server.

Hrm, good question.  I should think openssh-server would be support 5y as well.

Nick, can you check into this and confirm if this is accurate?

:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: qcow2 format state in Lucid

[Dustin Kirkland]

On Mon, Mar 22, 2010 at 12:39 PM, Nikolai K. Bochev
 wrote:
> I am quite curious about the state of qcow2 format in Lucid. As i recently
> discovered, when running a KVM machine with a qcow2 disk , i get a great
> performance hit under karmic. Seems that not only disk performance is
> decreased ( copying with 2 Mb/sec from the host to the guest and with around
> the same from the network to the guest ), but it hits the cpu on the guest
> pretty hard and the machine ( guest ) can become quite unstable. I know this
> is more of a  KVM/QEMU question, but i was wondering if anyone played around
> with Lucid already and with that part in particular. I have quite a few
> virtual hosts with lots of guests on them running on production environments
> and i want to know if i should just switch to raw format or wait until Lucid
> comes out and keep the qcow2 format of the disks.

I'm using KVM + qcow2 + virtio with Lucid host and Lucid guest quite
extensively.

Can you tell me more about your setup, as I'd like to see if I can
reproduce the problem you're seeing?

Specifically, what is your kvm command line when you're seeing the
problem, and what are you using to measure your performance or disk
throughput?

:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: what is the default admin password on Ubuntu Enterprise cloud?

[Dustin Kirkland]

On Thu, Mar 11, 2010 at 2:36 AM, Torsten Spindler  wrote:
> On Wed, 2010-03-10 at 21:59 +0200, Rudi Ahlers wrote:
>> Hi,
>> I installed the Ubuntu 9.10 Enterprise Cloud ISO, but I can't login to
>> https://192.168.2.166:8443/#login with the username & password admin &
>> admin,
>> Error: Username 'admin' not found
>
> At times it can take a little while for the interface to become
> accessible, waiting 5 to 15 minutes solved the problem for me all the
> time.

That should be reduced to about 2 minutes after boot for Lucid and the
latest SRU'd Karmic packages.

:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Server Bug Zapping -- Call for Participation!

[Dustin Kirkland]

[ Also posted at:
http://blog.dustinkirkland.com/2010/02/server-bug-zapping-call-for.html
]

In October 2009, just before the release of Ubuntu 9.10 (Karmic),
Mathias Gug, Dan Nurmi, and I holed up for a couple of very long days,
working on the Ubuntu Eucalyptus package. Over the course of 72 hours,
we uploaded Eucalyptus 7 times, fixing over 30 bugs. While Mathias,
Dan, and I were co-located, we were also greatly assisted by Thierry
Carrez (located +7 hours ahead) and community member Joseph Salisbury.
Thierry and Joe helped tremendously with regression testing of the
rapid fire uploads, triaging and squashing any new issues as they
arose. This "push" was essential to delivering UEC for Ubuntu 9.10.

Well, the Server Team is going to do it again, for Ubuntu 10.04, and
covering several other important server packages in addition to
Eucalyptus, and we're hoping to get your help this time.

We're calling this effort Server Bug Zapping. The plans are detailed here:
* https://wiki.ubuntu.com/ServerLucidBugZapping

The idea is that rather than waiting around for bugs to "get fixed",
we're going to take a more proactive approach.

We're arming a platoon of Ubuntu Server Developers, Community Members,
and Triagers, deploying them out on timed, coordinated missions,
focusing our efforts on a particular packages for about a week at a
time.

The first mission commences next week, March 1 - 5, 2010, targets our
Virtualization stack, focusing on:
* qemu-kvm
* lxc
* libvirt

Anthony Liguori (upstream QEMU maintainer) has agreed to help us next week, too.

If you have a particular interest in seeing these packages solid and
successful in Ubuntu 10.04 LTS Server, then please lend a hand!

Even if you're not a developer, we need quite a bit of help triaging
the bugs, testing the new Lucid packages, confirming old bugs against
the latest code, and verifying the the latest code fixes others!

Here's the plan:
* Monday - total bug triage
  o prioritize all bugs according to a defined formula
  o confirm/reproduce any bugs in the "new" state
  o triage any bugs in the confirmed state, ie, identify the
problem, test workarounds or solutions
  o expire any bugs that are invalid
  o fix-release any bugs that cannot be reproduced on the latest code
  o assign yourself (or others) triaged bugs that they can fix
  o time permitting, start working on fixes
* Tuesday
  o bzr branch (or apt-get source) the latest lucid code
  o work on fixes, pushing to lp:~yourname/thepackage/bugnumber
  o build a package in your PPA for testing
  o get some else to verify your PPA build
  o uploader will roll all fixes into an upload for that day
* Wednesday
  o same as Tuesday
* Thursday
  o same as Tuesday, rolling toward a "final" release by the
end of the day
* Friday
  o Comprehensive regression testing
  o Generate status report on total uploads, bugs triaged,
bugs fixed, participation
  o Post to ubuntu-server@ mailing list and the ubuntu-server blog

If you would like to get involved, please:

   1. Join the ~bug-zappers team in Launchpad.net
 * https://launchpad.net/%7Ebug-zappers
   2. Subscribe to the specification and the blueprint
 * https://wiki.ubuntu.com/ServerLucidBugZapping?action=subscribe
 * 
https://blueprints.launchpad.net/ubuntu/+spec/server-lucid-bug-zapping/+subscribe
   3. Communicate with us in #ubuntu-server on irc.freenode.net
   4. Participate in the triage on Monday, and the bug fixing/testing
Tuesday - Friday, from March 1st - April 8th

Finally, the schedule of targeted packages is not yet set in stone.
The only two that are confirmed right now are March 1-5 (qemu-kvm,
lxc, libvirt), and March 22-26 (eucalyptus, euca2ools). If you have
suggestions of packages we should consider targeting, please let us
know on the Ubuntu-Server mailing list. Please consider packages that
meet the following criteria:
* heavily used, high value
* large number of (fixable or un-triaged) bugs
* active upstream
* and perhaps an upstream that's interested in participating in at
least part of a week of bug triage/fixing

Cheers,
:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: proposed universe demotion: virt-manager (or, a request for active maintenance)

[Dustin Kirkland]

On Sat, Jan 30, 2010 at 3:30 AM, Nikolai K. Bochev
 wrote:
> I am currently ( karmic ) using virt-manager from a PPA ( 
> https://launchpad.net/~dnjl/+archive/virtualization ) along with libvirt and 
> qemu/kvm from there. It would be really nice if virt-manager gets the needed 
> attention, since for now it is really the only viable option if you want to 
> work with KVM under a graphical environment. Not to mention it's the only way 
> to actually view a console of virtual machines and easy add/remove 
> devices/ram/whatever again to a remote KVM server ( yes i know and i can use 
> the CLI commands, but it's a different experience ). You can actually view 
> the cpu/net/hdd loads with virt-manager in real time also, the CLI doesn't 
> give you that , at least not in such a nice way. If ubuntu wants to push KVM 
> as virtualization tech, you should support all the tools for it.

So again, I'm not debating the utility of virt-manager -- I think it
certainly is a useful tool that fits a need that you and other users
have.

And I'm certainly not suggesting that we drop it from the archive, but
rather move it from Main to Universe such that our stated support
model actually matches the reality we have -- it's a GUI program that
the Ubuntu Server Team doesn't maintain, and a Server-related program
that doesn't fit the Desktop Team's current charter.

:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: proposed universe demotion: virt-manager (or, a request for active maintenance)

[Dustin Kirkland]

On Fri, Jan 29, 2010 at 12:04 PM, Vishal Rao  wrote:
> For a regular user who wants a UI frontend to operate KVM etc, what
> are my options?
> Right now I am quite forced to move to VirtualBox/VMware because I'm
> too noobish to work with the command line.

Let me reiterate ...  I am not proposing that we drop it from the
archive, but merely move it from Main to Universe.

We use (and depend) on dozens of packages every day that are in
Universe.  You would not lose access to virt-manager, but rather the
stated support for the package would actually line up with the reality
I feel we currently have.

:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: proposed universe demotion: virt-manager (or, a request for active maintenance)

[Dustin Kirkland]

On Sat, Jan 30, 2010 at 5:25 AM, Martin Pitt  wrote:
>>  a) the Ubuntu Desktop Team provides active maintenance of virt-manager, or
>>  b) virt-manager is demoted to Universe for Lucid.
>
> If someone in the Desktop team feels very attached to virt-manager,
> taking up maintenance would be nice, but speaking for my own, it's so
> much easier to use the CLI.. Also, it's not anywhere near the
> stated goals of the desktop team, so it would be a kind of hobby
> project only.

Understood, and it's python-gtk GUI nature puts it a bit out of the
scope of the server team too (since Ubuntu Servers do not run X),
leaving it in this under-attended gray area.

> If it's not really getting maintenance from core devs, but needs some,
> then demotion sounds appropriate.

Ack, I agree with your wording.

:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

proposed universe demotion: virt-manager (or, a request for active maintenance)

[Dustin Kirkland]

Hi,

virt-manager, while being perhaps the only decent GUI for managing
KVM/Xen/QEMU guests in Ubuntu, is largely unmaintained.  Bugs pile up
that we do very little about.
 * https://bugs.launchpad.net/ubuntu/+source/virt-manager
 * 113 bugs, 70+ untriaged


This is primarily due to the nature of virt-manager...  It's *really*
a graphical desktop application (python-gtk), but mostly falls under
the domain of the Ubuntu Server Team, which does not deal with
graphical applications, and thus virt-manager does not get the
attention it deserves.  The Server Team does actively maintain the
non-GUI guts of virt-manager (that being libvirt and qemu-kvm), as
well as other numerous non-graphical tools for managing virtual
machines (virsh, UEC, euca2ools, vmbuilder, etc.).

I propose that either:
 a) the Ubuntu Desktop Team provides active maintenance of virt-manager, or
 b) virt-manager is demoted to Universe for Lucid.

As noted on each of these proposed demotions, this doesn't mean
virt-manager would leave the archive.  Merely that it's an apt-get
install from Universe away (which is actually already the case --
virt-manager is currently only seeded on the Ubuntu DVD).

I would much prefer (a), however, if (a) cannot happen, I think (b) is
the most appropriate action, as without a more active maintainer of
the project.  Placement in Universe would more accurately reflect the
support model virt-manager has endured for the last ~2 years, and
possibly even invigorate more support, with all of MOTU having
privileges to fix bugs.

/me dons his firefighting gear, in advance of the oncoming flames...

Thanks,
:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Earth Computing

[Dustin Kirkland]

On Tue, Dec 15, 2009 at 6:40 AM, Alvin  wrote:
...
> This is a real-life scenario. Is it common? I don't know. It's not free of
> struggles as you can see. So, this is a plea for quality. Cloud Computing
> might be very important, but please don't lose sight of the little guys who
> just want some 'classic' servers.

As one of the Canonical Ubuntu Server Developers working on our Ubuntu
Enterprise Cloud, I'll respond to this ...

We absolutely have a focus on quality for the "classic servers", as
you call them.  Basic Ubuntu Servers are our foundation, truly, for
all of our Cloud Computing efforts, both as a Virtualization Guest,
and a Virtualization Hypervisor.

Your email is well constructed, and having a targeted bug list is an
excellent start.  My guidance to you would be:
 * Help get each of those bugs into a triaged state, and with an
appropriate priority set, and filed against the correct package.
 * Re-test them with the latest development code, the 10.04 release
that's under development.
 * Provide all the information you possibly can to help a developer
work to solve those problem.
 * Nominate them for release, probably targeting Ubuntu 10.04 Lucid at
this point.
 * If you have hacks, work arounds, fixes, or patches, please, by all
means, attach them to the bugs, as again, this will help a developer
get an appropriate fix into Ubuntu sooner than later.
 * And have just a bit of patience and understanding that we have 100s
(or 1000s) of bugs, and merely a 5-person Ubuntu Server Team in
Canonical (plus a few dozen more Ubuntu and Debian community members
that help out).

:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: No X version of notify-reboot-required

[Dustin Kirkland]

As Nick mentioned, try "byobu".

It's a nicer, friendlier, customized GNU screen session.

At the bottom of the screen, it will show you a regularly updated
indicator, showing the number of updates available for your system,
and (R) if a reboot is required (among other interesting system data).

:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Server Team 20100120 meeting minutes

[Dustin Kirkland]

On Thu, Jan 21, 2010 at 5:27 AM, Thierry Carrez
 wrote:
> List at [4] still needs to be cleaned up to be more useful.
>
> [4]
> http://qa.ubuntu.com/reports/team-assigned/canonical-server-assigned-bug-tasks.html
>
> Action: zul, kirkland to unassign themselves from "maybe working on one
> day" bugs

Two comments here ...

First to the usefulness of that list...  I don't like it at all that
this list is cached data.  It's always out of date.  I've closed
several of these bugs today, and they're still on this list.  For this
list to be useful, it needs to be more up-to-date.

Second, I actually would like to track my "maybe working on one day"
bugs.  Perhaps I'll work on them in my own time, or as a community
member, or as a MOTU.  For this reason, it makes sense to use the
owner field in Launchpad.  Can we, perhaps, tag them somehow, and
filter on that to generate this report?  Adding a "spare-time" tag, or
something like that?

:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

ubuntu-server meeting minutes from 2010-01-06

[Dustin Kirkland]

Howdy,

Here are the minutes of this week's meeting. They can also be found
online with the irc logs here:
https://wiki.ubuntu.com/MeetingLogs/Server/20100106.

## page was renamed from MeetingLogs/Server/20100107
== Agenda ==

 * Review ACTION points from previous meeting
 * Discuss some specs that were not targeted to alpha2:
   * 
[[https://blueprints.launchpad.net/ubuntu/+spec/server-lucid-aws-client-libraries|server-lucid-aws-client-libraries]]
(mathiaz)
   * 
[[https://blueprints.launchpad.net/ubuntu/+spec/server-lucid-asterisk-integration|server-lucid-asterisk-integration]]
(dyfet, Daviey)
   * 
[[https://blueprints.launchpad.net/ubuntu/+spec/server-lucid-cluster-stack|server-lucid-cluster-stack]]
(RoakSoax, ivoks)
   * 
[[https://blueprints.launchpad.net/ubuntu-docs/+spec/lucid-serverguide|lucid-serverguide]]
(sommer)
   * 
[[https://blueprints.launchpad.net/ubuntu/+spec/server-lucid-contextualization|server-lucid-contextualization]]
(stgraber)
 * Check blueprint status and progress for the week
 * Assigned and to-be-assigned bugs:
http://qa.ubuntu.com/reports/team-assigned/canonical-server-assigned-bug-tasks.html
 * Weekly Updates & Questions for the QA Team (soren)
 * Weekly Updates & Questions for the Kernel Team (jjohansen)
 * Weekly SRU review (mathiaz)
   * [[https://wiki.ubuntu.com/ServerTeam/KnowledgeBase#SRU%20weekly%20review]]
 * Open Discussion
 * Agree on next meeting date and time

== Minutes ==

 Previous actions points 
 * JosBoumans to talk to ColinWatson and HughBlemings about taking
over eCryptfs support/maintenance

 Non-alpha2 targeted specs for lucid 
 * UbuntuSpec:server-lucid-aws-client-libraries
  * MathiasGug needs input from community on which libraries to package
  * MathiasGug to send an email to ubuntu-cloud@, ubuntu-ec2@ and blog about it
  * '''ACTION''' jib to complete Perl list for AWS client libs
  * '''ACTION''' nijaba to complete PHP list for AWS client libs
  * '''ACTION''' Mathiaz to send out AWS Client lib RFC
  * '''NOTE''': Regarding the Perl API, EricHammand notes: ''There is
a *different* Amazon::SimpleDB on CPAN which is not high quality, not
maintained, and the author did not respond to my questions about its
status.  My ideal solution would be for Amazon's package to be renamed
to Net::Amazon::SimpleDB and added to CPAN and then
libnet-amazon-simpledb in Ubuntu.''
 * UbuntuSpec:server-lucid-cluster-stack
  * ivoks has it packaged at
https://edge.launchpad.net/~ivoks/+archive/ppa/+packages
  * pacemaker might be a decent replacement for redhat-cluster-suite
  * ivoks to blog a call for testing
  * ivoks to add work items to his blueprint
  * '''ACTION''' ivoks to update server-lucid-cluster-stack with lucid
(and alpha3) goals
 * UbuntuSpec:lucid-serverguide
  * AdamSommer suggests a weekly meeting item, asking for server guide changes
 * UbuntuSpec:server-lucid-contextualization
  * not yet targeted, StefanGraber says updated userspace + tested
libvirt could be targeted at Alpha3
  * SorenHansen mentioned some potential issues between LXC and upstart
  * lxc needs an MIR, should be straight-forward, StefanGraber to file the MIR
  * libvirt 0.7.5
   * JamieStrandboge mentions that it would be nice to get libvirt
0.7.5 into Lucid, StefanGraber agrees, as there are some LXC
enhancements in 0.7.4
   * JamieStrandboge will do the merge
   * Long discussion ensued, see the full log
 * UbuntuSpec:server-lucid-asterisk-integration
  * '''ACTION''': jmdault to update server-lucid-asterisk-integration
blueprint with alpha3 & post-alpha3 workitems and change syntax to
match Pitti's workitems WorkItemsHowto
 * UbuntuSpec:server-lucid-papercuts
  * '''ACTION''': ThierryCarrez to send background mail on papercuts
project for next weeks discussion

 blueprint status check 
 * UbuntuSpec:server-lucid-uec-testing - 12/0/13 52%
  * MathiasGug says still on track
 * UbuntuSpec:server-lucid-ec2-config - 8/0/2 20%
  * ChuckShort, ScottMoser say still on track
 * UbuntuSpec:server-lucid-ec2-boothooks - 10/0/3 23%
  * ScottMoser is confident
 * UbuntuSpec:server-lucid-eucalyptus-merging-and-packaging
  * DustinKirkland says on track
 * UbuntuSpec:server-lucid-euca2ools
  * DustinKirkland says on track

 assigned bugs:
http://qa.ubuntu.com/reports/team-assigned/canonical-server-assigned-bug-tasks.html

 * Keep your bugs up to date

 weekly Q&A with QA 
 * SorenHansen has nightly builds of some server packages
  * libvirt, postgresql, mysql, openldap, php5
 * '''ACTION''': SorenHansen to solicit packages that lend them selves
well to nightly builds
 * '''ACTION''': ScottMoser to investigate publishing new AMIs

 Q&A with the kernel team (jjohansen) 
 * Kernel still open for config changes
 * ThierryCarrez asked about Bug:499785 and Bug:499491
  * JohnJohansen says kernel will be uploaded Monday or Tuesday

 weekly SRU review (MathiasGug) 
 * Jaunty, Bug:117736
  * to decline
 * Karmic, Bug:379329
  * to be handled by Securi

Re: Eucalyptus and ubuntu images

[Dustin Kirkland]

On Mon, Jan 4, 2010 at 10:38 AM, Alon Girmonsky  wrote:
> Can anyone recommend a good tutorial on how to create images to Eucalyptus.
> I would like to create  a karmic version for Eucalyptus running on Ubuntu
> EUC.
> I've been spending several days now, with no real success.

https://help.ubuntu.com/community/UEC/BundlingImages

:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Eucalyptus UEC-003 Test Results

[Dustin Kirkland]

On Wed, Oct 14, 2009 at 4:53 PM, Joseph Salisbury
 wrote:
> Yes my issue does look very similar to bug 448671.  I can either stay
> with this i386 install and help test for this bug.  Or, I could
> install x86_64 and see if the issue goes away?  Do you have any
> preference?

Most of us here are testing with amd64.

I actually find it interesting and useful that you're covering i386!

:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Re: Re: Eucalyptus UEC-003 Test Results

[Dustin Kirkland]

On Mon, Oct 12, 2009 at 10:23 AM,   wrote:
> I got it working. I just copied what you did to your files in the bug report
> ;-) I can now access the Node from the network. I attached my original
> interfaces file and a modified working file to the bug. I can re-run the
> steps in UEC-003 now that the node is available. Any other specific tests I
> should try?

Can you try running instances, as described at the bottom of that bug?

If you get to that, then you should be pretty proud of yourself...
You have a working cloud ;-)

:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Re: Eucalyptus UEC-003 Test Results

[Dustin Kirkland]

On Mon, Oct 12, 2009 at 10:08 AM,   wrote:
> I re-installed the node. However, the DHCP request during the install timed
> out and failed. I ensured the Cluster was up and running and the
> avahi-daemon and avahi-publish processes were running.
>
> I went ahead and re-installed using a static IP address to at least get the
> Node up. However, I'm back in the state where the Node is not accessable
> from the network again. The Node can ping out to the netowork, but it cannot
> be seen on the network to get in. I will try to massage the interfaces file
> like was done in bug 446023. I'll attach the bad interfaces file and a good
> one if I can get things working.
>
> Just let me know if you want me to try anything specific to debug the DHCP
> failure during install.

If you post your interfaces file here, we can probably help you work through it.

:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Eucalyptus UEC-003 Test Results

[Dustin Kirkland]

On Sat, Oct 10, 2009 at 9:30 PM, Joseph Salisbury
 wrote:
> On Sat, Oct 10, 2009 at 7:45 PM, Dustin Kirkland
>  wrote:
>> On Fri, Oct 9, 2009 at 8:10 PM, Joseph Salisbury
>>  wrote:
>>> I don't believe that my node was found.  But then again, I never told
>>> the Cluster what my nodes IP address(Or MAC Address) was, so how could
>>> it know how to address it?  During the Cluster installation, I
>>> specified some Virtual IP Addresses that will be used(Step 26 of
>>> UEC-001), but nothing specific to a node.  Should the be a step in
>>> UEC-003 to do something like: sudo euca_conf -addnode
>>> IP_ADDRESS_OF_NODE ?
>>
>> You node should have been installed to use DHCP.
>
> During the Node installation, I canceled the DHCP request, so I could
> configure interface eth0 with a static IP address.  Should I not have
> configured the interface as a static IP address?  If so, would the
> Node have gotten one of the virtual IP addresses specified during the
> Cluster install?  What if there is another DHCP server on the same
> network?  Do the Nodes need to be on a private net with the Cluster?
>
>
>>
>> After installation, it should be broadcasting that its a eucalyptus
>> node by avahi.
>>
>> The discover-nodes command should pick up that avahi broadcast, and
>> detect the ip address, and prompt you to add the node.
>>
>> If that's not working, there's probably a bug somewhere.
>
> Maybe this is also related to bug:
> https://bugs.edge.launchpad.net/ubuntu/+source/eucalyptus/+bug/446023
> The Node is not acessable via the network using the static IP address
> I configured(After canceling the DHCP request).  I can run a wireshark
> trace to check if the Node is broadcasting that it is a eucalyptus
> node by avahi..
>
> I can also try to re-install the Node and let it grab an IP address via DHCP.

Yeah, try that.

I'm pretty sure our installer is screwing up static IP address
configuration when installing Eucalyptus.


-- 
:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Eucalyptus UEC-003 Test Results

[Dustin Kirkland]

On Fri, Oct 9, 2009 at 8:10 PM, Joseph Salisbury
 wrote:
> I don't believe that my node was found.  But then again, I never told
> the Cluster what my nodes IP address(Or MAC Address) was, so how could
> it know how to address it?  During the Cluster installation, I
> specified some Virtual IP Addresses that will be used(Step 26 of
> UEC-001), but nothing specific to a node.  Should the be a step in
> UEC-003 to do something like: sudo euca_conf -addnode
> IP_ADDRESS_OF_NODE ?

You node should have been installed to use DHCP.

After installation, it should be broadcasting that its a eucalyptus
node by avahi.

The discover-nodes command should pick up that avahi broadcast, and
detect the ip address, and prompt you to add the node.

If that's not working, there's probably a bug somewhere.

:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Eucalyptus UEC-003 Test Results

[Dustin Kirkland]

On Fri, Oct 9, 2009 at 6:54 PM, Joseph Salisbury
 wrote:
> I completed the testcase UEC-003 as it is listed on:
> http://testcases.qa.ubuntu.com/Install/ServerEConfig
>
> There were no errors reported during any of the steps listed in the
> testcase.  However, I did notice that there was not a step listed to
> specifically add the "Node Controller" installed in testcase UEC-002.
> Then again, I'm still fairly new with Eucalyptus ;-)
>
> One thing I did notice was that the "Node Controller" was not
> available on the network(Or from the Cluster Controller) via ssh,
> ping, etc by using the IP address specified during installation.
> Maybe this is to be expected?

Joe-

Thanks so much for responding to our call for testing.

Step 1 on that page should have found your node on your network:

   1. On Cluster search and confirm the addition of the node, type
  sudo euca_conf --no-rsync --discover-nodes

However, if your node is not responding to network traffic, then it
won't be discoverable.

Did you configure the networking of that Node Controller to use static
networking?  Also, do you have more than one network interface?  If
you answer "yes" to either question, I suspect you're hitting:
 * https://bugs.edge.launchpad.net/ubuntu/+source/eucalyptus/+bug/446023

If this looks like your bug, would you please attach your Node's
/etc/network/interfaces file to that bug?

Thanks,
:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: qemu-kvm changes coming...

[Dustin Kirkland]

On Mon, Aug 24, 2009 at 1:10 PM, James Dinkel wrote:
> After some searching, I think this must be the discussion you are talking
> about: http://lists.gnu.org/archive/html/qemu-devel/2009-02/msg00295.html
>
> I'm linking it here in case anyone else is interested.  From that discussion
> and reading elsewhere, it sounds like VirtualBox may be the forward solution
> to virtualization on non-vmx/non-svm hardware.
>
> Does Canonical or any Ubuntu virt developers have any concern for
> virtualization on non-vmx/non-svm hardware?  And what do you (they, anyone)
> think of vbox as the Ubuntu solution to fill this void?

As far as I'm aware, there are no virtualization-on-non-VT-hardware
packages in Ubuntu's main repositories.  i.e.. kqemu, vbox, xen are
all in Universe.  Canonical traditionally focuses the majority of its
efforts in delivering and supporting the packages in Ubuntu main.

I have very little experience with Virtual Box.  Sorry.

:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: qemu-kvm changes coming...

[Dustin Kirkland]

On Fri, Aug 21, 2009 at 3:32 PM, James Dinkel wrote:
> On Fri, Aug 21, 2009 at 3:11 PM, Dustin Kirkland 
> wrote:
>>
>> (I hope to evoke the diplomacy demonstrated by our revered Colin
>> Watson when he tells you that grub2 *might* eat your kittens.)
>>
>> Ubuntu's virtualization packages (kvm, qemu -> qemu-kvm) are about to
>> undergo a change that might introduce some inconveniences over the
>> next few days.  Hopefully not.  But maybe.  As discussed at UDS,
>>  *
>> https://blueprints.edge.launchpad.net/ubuntu/+spec/server-karmic-kvm-qemu-packaging
>
> Is this going to affect kqemu any?  Kqemu is a snap to install and pull in
> the qemu dependency on Intrepid and Jaunty, and I hope this first class
> treatment of kqemu doesn't go away as I still have several servers that
> don't support kvm.

Hi-

At this point, we have no intention on touching the kqemu package
(which is separate from qemu).  And the qemu-kvm version we're using
in Karmic is 0.11, which still supports kqemu.

However, upstream has completely dropped kqemu support in 0.12, so I
wouldn't plan on having kqemu support beyond Karmic.  See the qemu
mailing lists for *lengthy* discussion on this topic, which I'd rather
not duplicate here.

:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

qemu-kvm changes coming...

[Dustin Kirkland]

(I hope to evoke the diplomacy demonstrated by our revered Colin
Watson when he tells you that grub2 *might* eat your kittens.)

Ubuntu's virtualization packages (kvm, qemu -> qemu-kvm) are about to
undergo a change that might introduce some inconveniences over the
next few days.  Hopefully not.  But maybe.  As discussed at UDS,
 * 
https://blueprints.edge.launchpad.net/ubuntu/+spec/server-karmic-kvm-qemu-packaging

I'm writing here to warn you about this, and invite you to file bug
reports as necessary.  My apologies in advance for any issues.
 * https://bugs.edge.launchpad.net/ubuntu/+source/qemu-kvm/+filebug

Basically, a single qemu-kvm package (currently in Universe -- please,
by all means, start testing it now! -- but moving to Main soon, LP:
#417107) will replace the kvm package (which will become a stub
transitional package depending on qemu-kvm).  A second binary package,
qemu-kvm-extras, will provide all of the non-x86, non-accelerated
architectures traditionally provided by qemu (which should also become
a stub transitional package).

If you're a libvirt user (ie, virsh, virt-manager, eucalyptus, etc),
you shouldn't notice any change.  If you do, well that's a bug.
Please help shake those out before we unleash Karmic on our non-devel
users.

Why the changes?  Having two different copies of the same code (kvm,
qemu) has been very painful from a maintenance perspective.  Security
fixes and CVEs have to be rolled against multiple source packages,
built, verified, etc.  Fortunately, the upstream projects are merging
(which will hopefully be complete around our next Ubuntu release), and
the qemu-kvm releases provided by upstream are the first step in that
direction.  Furthermore, the upstream projects are also committing to
provide support and fixes that apply to the qemu-kvm branch (but not
for the kvm and qemu releases, which are intended for developers
only).  The kernel pieces of kvm are now significantly more mature,
and are already in our Ubuntu kernels.

What if you still want to run qemu?  We have setup daily builds (qemu,
qemu-kvm, libvirt) in the ~ubuntu-virt Launchpad PPA.  If you're
interested in bleeding edge qemu, qemu-kvm, or libvirt, I invite you
to use those.
 * https://edge.launchpad.net/~ubuntu-virt/+archive/virt-daily-upstream

-- 
:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

libvirt backport

[Dustin Kirkland]

A big thanks to everyone who has been testing the backport of Jaunty's
kvm-84 to Intrepid and Hardy.

I have backported a bit more of the virtualization stack from Jaunty
to Intrepid and Hardy, namely:
* libvirt 0.6.1

Packages are available in the ~ubuntu-virt PPA:
* https://launchpad.net/~ubuntu-virt/+archive/ppa

I'm hoping some of you out there might be willing and interested to do
some testing on these new packages. They fix a couple of bugs for me,
including installation of Windows guests on Hardy hosts.

Please file bugs in Launchpad for any issues under libvirt, and add
the tag 'libvirt-backport'.  Also, if you find that this package fixes
any bugs for you, please note that as well.

Cheers,
:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Call-for-Testing: KVM in Jaunty-Proposed [was Re: Call-for-Testing: KVM-84 Backport]

[Dustin Kirkland]

So we're now rounding 3rd base on the kvm-84 backport.

I've produced a couple of release candidates and fixed a few remaining
issues. Thank you to everyone who has tested the PPA packages and
provided feedback.

The final step before releasing the backport is to ensure that these
latest changes get uploaded to jaunty-updates, such that the package
is in sync among Hardy, Intrepid, and Jaunty.

So I've been working hard on this, and I'm at a point where I require
assistance from you, the community. I get emails on a weekly basis
from people asking for advice on getting involved in Ubuntu. Here's
your shot ;-)

There is a package in jaunty-proposed that needs to be pushed to
jaunty-updates before the Hardy and Intrepid backports can take place.
In order to promote the package to jaunty-updates, I need users to
verify that the new package fixes the four bugs that I think it fixes,
and does not cause regressions.

Please, if you have a system running Jaunty + KVM, give the -proposed
package a shot, and provide feedback in the following 4 bugs:

* 392295
* 359447
* 394953
* 382077

Thanks,
:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Call-for-Testing: KVM-84 Backport

[Dustin Kirkland]

Howdy,

Ubuntu 8.04 LTS was the first of the major server distributions to
ship KVM as the preferred hypervisor for virtual machine hosting.
KVM's upstream development has proceeded at a vigorous pace--faster
than Ubuntu's other server cornerstones (LAMP, Samba, Bind, Postfix,
etc).

The major version of the KVM userspace shipped in 8.04.2 LTS (kvm-62),
and the kvm kernel module in linux-2.6.24 are affected by several key
architectural issues that cannot be solved through cherry-picked
patches.

On March 17, 2009, I posted the following call for testing:
 * 
http://blog.dustinkirkland.com/2009/03/ubuntu-server-kvm-call-for-testing.html

We have worked through a number of the issues raised after that blog
post, and cherry-picked several patches that fix some known bugs.  We
believe that Ubuntu 9.04's kvm-84 is a far more complete hypervisor.

This is a call for one more round of testing of a release-candidate
build of that package (kvm - 1:84+dfsg-0ubuntu12.1~rc1) in the
ubuntu-virt ppa:
 * https://launchpad.net/~ubuntu-virt/+archive/ppa

If you are able to assist us with the testing, please add that PPA,
and install both the userspace and dkms built kernel module onto your
8.04 and/or 8.10 servers.
 $ sudo apt-get install kvm kvm-source

Please file any bugs against kvm in Launchpad, and please tag them
with "kvm-84".
 * https://bugs.launchpad.net/ubuntu/+source/kvm

The goal is to upload a version of kvm-84 to the hardy-backports and
intrepid-backports repositories around July 6, 2009.
 * https://help.ubuntu.com/community/UbuntuBackports

Thank you,
-- 
:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: erase ubuntu

[Dustin Kirkland]

On Mon, Jun 8, 2009 at 3:52 PM, James Dinkel wrote:
> Or if you wanted to really destroy all the data and make sure it is
> unrecoverable, you could boot to a livecd, open a terminal and run this: "dd
> if=/dev/zero of=/dev/sda" making sure that /dev/sda is the harddisk that you
> want to wipe out.

Depending on your paranoia level, you might also consider shred, which
can also run from a live cd.

 * http://manpages.ubuntu.com/manpages/jaunty/en/man1/shred.1.html

:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Your Distro is Insecure: Ubuntu

[Dustin Kirkland]

My response is at:
 * http://blog.dustinkirkland.com/2009/04/your-article-is-incorrect.html

:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: ServerGUI: where to discuss the shown "alternatives"?

[Dustin Kirkland]

On Tue, Mar 10, 2009 at 5:57 AM, Marc Luethi  wrote:
> I've been using the ServerGUI document as reference in a post in
> ubuntuforums.org, in a vague hope to tame down the ever resurgung
> discussions about "GUI on server? yes/no". I found your name to be the
> last editor of the document, hence I chose to contact you.

Hello-

> One of the wisdoms that is condensing out of the forum discussions is to
> suggest  to (especially novice) users to install Ubuntu Desktop and add
> the services (Apache, MySQL, Samba ...) manually, much the way they
> would have to on server as well. I believe that this alternative to a
> GUI install on the server is worth being mentionned (or linked to) in
> the ServerGUI document.

I strongly disagree with this approach for getting a GUI...

If you really must have a GUI, I suggest installing from the Server CD
first, which will get you a minimal installation, with the special
-server kernel.

Then, I would install a minimal desktop, without the "recommends"
packages, such as Open Office, Evolution, etc.  You can do this with:

  $ sudo apt-get install ubuntu-desktop --no-install-recommends

For an even more minimal system, you could also try xubuntu-desktop.

You can then, as you say, install whatever services you'd like on top
of that system (Apache, MySQL, Virt-Server, etc).  Of course, note
that you are running the Ubuntu Desktop, plus some services, but you
are not running "The Ubuntu Server".

> Is there a place to discuss this? I think I could manage to just go
> ahead and edit the ServerGUI document, but I'd like to discuss that
> first to see and learn what other people had in mind when they were
> writing. There does not seem to be a ./PageDiscussion subpage for
> ServerGUI - where would I find people interested in/maintaining the
> ServerGUI page?

There are 3 places where I'd recommend discussing this:

 1) the #ubuntu-server IRC channel
 2) the ubuntu-server@lists.ubuntu.com mailing list (CC'd here)
 3) the weekly Ubuntu Server Team meeting in IRC
  * https://wiki.ubuntu.com/ServerTeam/Meeting

Cheers,
:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: powernowd in server seed

[Dustin Kirkland]

On Thu, Sep 4, 2008 at 5:39 AM, Soren Hansen  wrote:
> I'm considering adding powernowd to the server seed, which means that it
> will be installed by default on server installs (unless you choose the
> minimal install method located in the "Modes" menu (press F4 to see it
> at the bootsplash)).  If the installed kernel supports the ondemand
> scaling governor, powernowd's init script simply tells the kernel to use
> that. If for some reason the kernel doesn't support this, it falls back
> to the userspace governor, spawns a daemon that monitors cpu usage and
> adjusts cpufreq accordingly. The win, of course, is that you'll save
> power, money, and the rain forest. :)

Polar bears and penguins too!

> Unless anyone objects, I'll file an FFe for this change, or at least
> queue it for Intrepid+1.

This item slipped through the cracks somewhere along the way...

I happened to notice that my Jaunty server installed earlier today
didn't have access to the cpu frequency scaling governors, and
installing powernowd fixed that.

I just added powernowd to the Ubuntu Server seed for installation.

Cheers,
:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Oracle9i

[dustin . kirkland]

On 1/29/09, Kaushal Shriyan  wrote:
> is there a step by step guide to install Oracle 9i Release 2 Database Server
> on Ubuntu 8.10 ?

Hi-

I don't know of such a guide, but if it existed, it would probably be
located with our community documentation at
http://help.ubuntu.com/community.

I just happened to be talking to Joe Salisbury (on CC) just the other
day about Oracle on Ubuntu.  He might know of a resource, or could
perhaps answer some of your questions.

:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Call for testing screen-profiles

[Dustin Kirkland]

On Sat, Jan 24, 2009 at 2:57 PM, Mark Schouten  wrote:
> On Sat, 2009-01-24 at 14:20 -0600, Dustin Kirkland wrote:
>> We could handle it, through update-alternatives, (see
>> /etc/alternatives).  I'll have a look at that.
>
> That's a possibility as well, although I guess that's only meant for
> binaries? (And, you must run it as root :))

Mostly...  It's also used for manpages that have multiple versions.
ls your /etc/alternatives directory.

:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Call for testing screen-profiles

[Dustin Kirkland]

On Sat, Jan 24, 2009 at 2:21 AM, Mark Schouten  wrote:
> 1: I have no objection to depending on screen-profiles.
> 2: It should not be necessary to change the screen-package. If you
> include the plain-profile in the screen-profiles package, one can always
> switch back.

Well, I'm not including the "plain" profile.  I'm just symlink'ing to
it.  I'd rather not include the "plain" profile, since screen provides
that, and upstream Debian, from time to time, makes
modifications/fixes to it.

> 3: Why not give an extra option when running select-screen-profile as
> root, to install it system-wide? I would not like to see the
> ubuntu-thingie as default.
> 4: See 2

Running things as root is generally avoid in Ubuntu.

We could handle it, through update-alternatives, (see
/etc/alternatives).  I'll have a look at that.


:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Call for testing screen-profiles

[Dustin Kirkland]

On Sat, Jan 24, 2009 at 2:21 AM, Mark Schouten  wrote:
> /usr/share/screen-profiles/profiles/common: source 
> /home/marks/.screenrc-keybindings: No such file or directory

Run select-screen-profile again, and select "ubuntu".  It will touch
/home/marks/.screenrc-keybindings.  This is a new feature.  Or just
touch /home/marks/.screenrc-keybindings.

Chalk it up to the joys of a new package, and/or running Jaunty, our
development distribution.  Sorry.

-- 
:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Call for testing screen-profiles

[Dustin Kirkland]

Thanks for the feedback so far!

Based on the comments on this thread, I have made a number of changes
to screen-profiles that I hope you find a bit better.

 * I changed the default escape sequence back to ctrl-a, since this
matches most default expectations, and all of the documentation.

 * I merged some functionality from Nick Barcet, which adds a page in
the helper menu (F9); here, you can easily change your escape sequence
to some other key; this is stored and loaded from your
~/.screenrc/keybindings file;  this would be a good place to put any
additional customizations to your keybindings that you might prefer.

 * We're not launching screen by default.  This is a toggle, on a per
user basis, in the helper menu (F9)

 * I did add a "Recommends: screen-profiles" to the screen package,
such that it gets installed on the server.

 * At this point, it's still required that each user run
"select-screen-profile" and choose "ubuntu" to benefit from this
functionality.  I would like to consider:
  1. making screen *depend* on screen-profiles
  2. moving the default /etc/screenrc installed by screen to something
like /etc/screenrc.plain
  3. installing the ubuntu profile to /etc/screenrc such that all
Ubuntu screen users have the ubuntu screen profile by default
  4. maintaining the ability to switch *back* to the plain profile
through select-screen-profile and the helper menu

Thoughts on the latter proposition?

:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Call for testing screen-profiles

[Dustin Kirkland]

On Thu, Jan 15, 2009 at 5:02 PM, Onno Benschop  wrote:
> I have no particular preference on the issue, but I would like to throw
> the following into the ring.
>
>* At one point I recall a discussion about making screen
>  automatically start when connecting to a server. Is that still the
>  case? Will that affect the outcome of this discussion?

That's configurable with the screen-profiles-helper.  If you bring up
the helper with F9, and go to the menu, there's a toggle to "launch
screen by default" or not.

I have a Main Inclusion request filed for screen-profiles.  Once it's
in main, I'd like to have "screen" depend on screen-profiles, and I'd
like to have the screen package add "source
/usr/share/screen-profiles/profiles/ubuntu" to the end of
/etc/screenrc.  And using select-screen-profile, you could switch it
back to the plain, non-customized one.

I think this would be a really neat, flashy addition to the Ubuntu server.

>* Would it be useful to make the default the same as screen has,
>  seeing that it's using screen, but make it configurable - system
>  wide, using dpkg-reconfigure. It could be smart enough to notice
>  that emacs is already installed - who uses that ;-) - and alert
>  the administrator.
>* Are we talking about installing this by default - seeing that
>  emacs doesn't appear to be installed by default.

Hmm, I must admit, I'm being swayed toward putting the default escape
sequence back to ctrl-a, and making sure that that's easy to change
with the helper.  Let's get some more opinions and votes.

:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Call for testing screen-profiles

[Dustin Kirkland]

On Thu, Jan 15, 2009 at 4:48 PM, Nicolas Valcárcel
 wrote:
> I have no problem with control-g now, i've been testing screen-profiles
> since the start and at the beginning it was quite hard (sometimes i
> still type cntrl-a before remembering that it's -g) but now i'm quite
> used to that, is just a change, as when someone change from an OS to
> other that is going to feel weird at the beginning but will love at the
> end.
>
> I'm happy with -g, but as kees said, that's what .screenrc is for.

Okay, so what I'm taking from this is that we should:
 a) have a sane, agreeable default for the escape sequence
 b) provide a simple way to change this using the
screen-profiles-helper configuration utility.

I filed a bug for (b) here:
 * https://bugs.edge.launchpad.net/ubuntu/+source/screen-profiles/+bug/317675

:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Call for testing screen-profiles

[Dustin Kirkland]

On Thu, Jan 15, 2009 at 4:09 PM, Mark Schouten  wrote:
> However, imho there are three points here:
> 1: Lot's of people do not have a clue what ctrl-a does. Since Ubuntu
> focuses on ease of use, it also automatically attrackts less experienced
> users who will not know what ctrl-a is.
> 2: Experienced screen-users will default to ctrl-a since that's what
> they're using for years.
> 3: Ctrl-a can be done using one hand. ctrl-a space/$digit switches
> windows. Maybe it's me, but I don't feel like pressing ctrl-g is a
> comfortable move, typing wise.
>
> Anywho, this is just my point of view. Maybe other screen users have a
> very different opinion. :)
>
> If there allready was an extensive discussion, don't let me be the one
> to start that process all over again. (But do consider my personal view
> above ;))

Ah, thanks for sharing your point of view!  That's what this is about.

I'm all for doing this democratically...  Let's get some proposals
(one of which can be to leave ctrl-a as the escape sequence), and run
a poll on Launchpad.

The floor is hereby open for proposals!

:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Call for testing screen-profiles

[Dustin Kirkland]

On Thu, Jan 15, 2009 at 2:50 PM, Mark Schouten  wrote:
> I'll try to use it for a while, see how it goes.

Thanks!

> Just a question though. Why is ctrl-a changed to ctrl-g?

On Ubuntu (and most Linux systems), the default shell uses emacs
keybindings.  As such, ctrl-a is very often used (if you're not an
emacs user) to move the cursor to the beginning of the line.

The default screen escape sequence, ctrl-a, breaks that.

We have had extensive discussions, and the consensus was that the
escape sequence would need to be changed.

We've settle on ctrl-g, which was proposed by Nick Barcet.  Perhaps he
can attest as to why ctrl-g was chosen?  Nick?

Perhaps we should conduct a poll in Launchpad?  I'd think that we can
change this escape sequence pretty much any time between now and
Jaunty's official release in April.  But I don't want to change it
more than once.

Shall we open the floor for other suggested escape sequences?  Please
explain your rationale for why your escape sequence is better than
ctrl-a and ctrl-g...

Cheers,
:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Call for testing screen-profiles

[Dustin Kirkland]

Hi Ubuntu Server-

I'm hoping there are a few people out there who are willing and
interested in testing the Ubuntu screen profile contained in the new
Jaunty Universe package, screen-profiles.  For more information and
screenshots:
 * 
http://blog.dustinkirkland.com/2009/01/ubuntu-jaunty-testing-screen-profiles.html

I've been testing it within gnome-terminal and on tty consoles.  I
haven't tried it within konsole, or other terminals.  I'd be keen to
get some feedback on those!

If you're running Jaunty, you can simply:
 $ sudo apt-get install screen-profiles

However, this same package works just fine on Hardy and Intrepid as
well.  In this case, you can download the latest .deb binary build
from:
 * http://us.archive.ubuntu.com/ubuntu/pool/universe/s/screen-profiles/

And install it with:
 $ sudo dpkg -i screen-profiles*.deb

Once it's installed, you will need to select the Ubuntu screen profile with:
 $ select-screen-profile

You should be greeted with a help window defining the hotkeys, and a
menu where you can perform a few other customizations, such as
toggling on/off whether screen should automatically launch on every
login.

I'm hoping to get a Main Inclusion Report filed this week to begin the
process of including this flashy new feature on the Ubuntu server iso.
 We're looking for some feedback first.

Please file bugs in Launchpad.  If you're interested in contributing
to Ubuntu server development, this project involves Shell and Python
code, and is maintained in bzr at lp:screen-profiles.

Cheers,
-- 
:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Server Team 20090106 meeting minutes

[Dustin Kirkland]

On Tue, Jan 6, 2009 at 4:12 PM, Mathias Gug  wrote:
>  Screen Profiles 
>
> kirkland has been collecting screen profiles and hacks to provide them in a
> screen-profile package. mathiaz asked if there were any plans to enable screen
> by default on an new Ubuntu Server installation. kirkland explained that he
> was aiming at getting it included into main and shipped on the server cd.
> Moreover the first time screen is run a list of profiles would be shown.
>
> Some work has been done on implementing a task bar in screen so that applets
> could be easily added.
>
> ACTION: kirkland to upload a new version of the screen-profile package

Done.  In queue at:
 * https://launchpad.net/ubuntu/jaunty/+queue

> ACTION: kirkland to create a wiki page to outline how-to implement a taskbar
> in screen

I don't think your "ACTION" quote is quite accurate here.  At least I
don't understand it, as written.

I took this "to-do" to mean creating the spec/design document of what
we're going for, with respect to screen-profiles.  As such, I created:
 * https://wiki.ubuntu.com/ScreenProfiles

Cheers,
:-Dustin

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam