Since 17.10, netplan has been the default network configuration tool in Ubuntu. Since then, it has grown in features, bug fixes, and even got its package renamed in the archive from "nplan" to netplan.io. We added better routing, improved handling for bridges, support for marking devices as "optional" for boot (so that the system doesn't wait for them to come up at boot time), lots of documentation updates... There's even been work to get it building for other distros.
We have a website for it, too: netplan.io
As we get closer to the release of Ubuntu 18.04, it is past due to involve everyone in testing netplan and making sure it is solid and as featureful as possible for a wide range of use cases.
This is where you get to participate.
Let us know about any feature gaps that remain in what
netplan supports, so that we can add the features when it's possible, or so that these feature gaps can be properly documented if they can't be closed by release time.
Report any bugs you find in netplan on Launchpad.
If you are unsure whether something is a bug, it might well be, so it doesn't hurt to file a bug. At the very least, we do want to know if something feels really difficult to do, so we can look into improving the experience.
If you're unsure how to do something you can look up questions and answers, or add your own, on AskUbuntu here:
https://askubuntu.com/questions/tagged/netplan
Netplan is being actively developed and we can use your help; so if there's one feature you care deeply about, or a bug that bugs you and you want to have a hand in fixing it, you can also jump right in to the code in Github: http://github.com/CanonicalLtd/netplan
Showing posts with label logiciel libre. Show all posts
Showing posts with label logiciel libre. Show all posts
Thursday, 15 March 2018
Wednesday, 7 March 2018
Backing up GPG keys
Using PGP/GPG keys for a long period of time (either expiring keys, or extending expiration dates) and the potential for travel, for hardware to fail, or for life's other events means that eventually rather than potentially, you will end up in a situation where a key is lost, damaged, or where you otherwise need to proceed with some disaster recovery techniques.
These techniques could be as simple as forgetting about the key altogether and letting it live forever on the Internet, without being used. It could also be that you were clever and saved a revocation certificate somewhere different than your private key is backed up, but what if you didn't?
What if you did not print the revocation certificate? Or you just really don't feel very much like re-typing half a gazillion character?
I wouldn't wish it to anyone, but there will always be the risk of a failure of your "backup options"; so I'm sharing here my personal backup methods.
I back up my GPG keys, which I use both at and outside of work, on multiple different media:
This retains the same security systems as your original key. You should have added a passphrase to it anyway, so even if the paper copy was found and used to recover the key, you would be protected by the complexity of your passphrase.
But this depends on OCR working correctly, especially on an aging medium such as paper, or you spending many hours re-typing the contents, and potentially tracking down typos. There's error correction, but that sounds to me like not fun at all. When you want to recover your key, presumably it is because you really do need it as soon as possible.
Back in 2015 when I generated my latest keys, I found a blog post that explained how to use QR codes to back up data. QR codes have the benefit of being very resilient to corruption, and above all, do not require typing. QR codes are however limited in size, being limited to 177x177 squares, for about 1200 characters storage.
Along with that blog post, I also found out about DataMatrix codes (which are quite similar to QR codes), but where each symbol can save a bit more data (about 1500 bytes per image in the biggest size). Pick the format you prefer, I picked DataMatrix. Simply modify the size you split to in the commands below.
One might wish to save the paperkey or the private key directly (obviously, saving the private key might mean more chunks to print), and that can be done using the programs in dmtx-utils:
You will be left with multiple parts of the file you originally split (without a file extension), as well as a corresponding image in PNG format that can be printed, and later scanned, to recover the original.
Keep these in a safe location and your key should be recoverable years down the line. It's not a bad idea to "pretend" there's a catastrophe and attempt to recover your key every few months, just to be sure you can go through the steps easily and that the paper keys are in good shape.
Recovery is simple:
If all went well, the original and recovered files should be identical, and you just avoided a couple of hours of typing.
Stay safe!
These techniques could be as simple as forgetting about the key altogether and letting it live forever on the Internet, without being used. It could also be that you were clever and saved a revocation certificate somewhere different than your private key is backed up, but what if you didn't?
What if you did not print the revocation certificate? Or you just really don't feel very much like re-typing half a gazillion character?
I wouldn't wish it to anyone, but there will always be the risk of a failure of your "backup options"; so I'm sharing here my personal backup methods.
I back up my GPG keys, which I use both at and outside of work, on multiple different media:
- "Daily use" happens using a Yubikey that holds securely the private part of the keys (it can't be extracted from the smartcard), as well as the public part. I've already written about this two years ago, on this blog.
- The first layer of backup is on a LUKS-encrypted USB key. The USB key must obviously be encrypted to block out most attempts at accessing the contents of the key; and it is a key that I usually carry on my person at all times, like the Yubikeys -- I also use it to back up other files I can't leave without, such as a password vault, some other certificates, copies of ID documents in case of loss for when I travel, etc.
- The next layer is on paper. Well, cardstock actually, to avoid wanting to fold it. This is the process I want to dig into deeper here.
It turns out that backing up secure keys on paper is pretty straightforward, and something just fine to do. You will obviously want to keep the paper copies in a secure location that only you have access to, as much as possible safe from fire (or at least somewhere unlikely to burn down at the same time as you'd lose the other backups).
paperkey is a generally accepted way of saving the private part of your GPG key. It does a decent job at saving things in a printable form, from which point you would go ahead and re-type, or use OCR to recover the text generated by paperkey:
paperkey --secret-key secret.gpg --output printme.txt
This retains the same security systems as your original key. You should have added a passphrase to it anyway, so even if the paper copy was found and used to recover the key, you would be protected by the complexity of your passphrase.
But this depends on OCR working correctly, especially on an aging medium such as paper, or you spending many hours re-typing the contents, and potentially tracking down typos. There's error correction, but that sounds to me like not fun at all. When you want to recover your key, presumably it is because you really do need it as soon as possible.
Back in 2015 when I generated my latest keys, I found a blog post that explained how to use QR codes to back up data. QR codes have the benefit of being very resilient to corruption, and above all, do not require typing. QR codes are however limited in size, being limited to 177x177 squares, for about 1200 characters storage.
Along with that blog post, I also found out about DataMatrix codes (which are quite similar to QR codes), but where each symbol can save a bit more data (about 1500 bytes per image in the biggest size). Pick the format you prefer, I picked DataMatrix. Simply modify the size you split to in the commands below.
One might wish to save the paperkey or the private key directly (obviously, saving the private key might mean more chunks to print), and that can be done using the programs in dmtx-utils:
cat printme.txt | split -b 1500 - part-
rm printme.txt
for part in part-*; do
dmtxwrite -e 8 ${part} > ${part}.png
done
You will be left with multiple parts of the file you originally split (without a file extension), as well as a corresponding image in PNG format that can be printed, and later scanned, to recover the original.
Keep these in a safe location and your key should be recoverable years down the line. It's not a bad idea to "pretend" there's a catastrophe and attempt to recover your key every few months, just to be sure you can go through the steps easily and that the paper keys are in good shape.
Recovery is simple:
for file in *.png; do dmtxread $file >> printme.txt; done
If all went well, the original and recovered files should be identical, and you just avoided a couple of hours of typing.
Stay safe!
Sunday, 29 March 2015
Preseeding installations
In early February, I completed a move from Canonical's Phonedations team to the Foundations team. Part of this new work means debugging a lot of different failure cases in the installer, grub, and other early boot or low-level sofware, some of which requiring careful reproduction steps and probably quite a few install runs in VMs on on hardware.
Given the number of installations I do I've started to keep around preseed files; the text files used to configure automatic installations. I've made them available at http://people.canonical.com/~mtrudel/preseed/ so that they can be reused as necessary. Most of these preseed files make heavy use of the network to get the installation data and packages from the web, so they will need to be tweaked for use in an isolated network. They are annotated enough that it should be possible for anyone to improve on them to suit their own needs. I will add to these files as I run across things to test and automate. I hope we can use some of them soon in new automated QA tests where appropriate, so that it can help catch regressions.
For those not familiar with preseeding, these files can be used and referred to in the installation command-line when starting from a network PXE boot or a CDROM or pretty much any other installation medium. They are useful to tell the installer how you want the installation to be done without having to answer all of the individual questions one by one in the forms in ubiquity or debian-installer. The installer will read the preseed file and use these answers without showing the prompts. This also means some of the files I make available should not be used lightly, as they will happily wipe disks without asking. You've been warned :)
To use this, you'll want to specify "preseed/file=/path/to/file" (or just file=) for a file directly accessible as a file system or through TFTP, or "preseed/url=http://URI/to/file" (or just url=) if it's available using HTTP. On d-i installs, this means you may also need to add "auto=true priority=critical" to avoid having to fill in language settings and the like (since the preseeds are typically only read after language, country, and network have been configured); and on ubiquity installs (for example, using a CD), you'll want to add 'only-ubiquity automatic-ubiquity' to the kernel command-line, again to keep the automated, minimal look and feel.
I plan on writing another entry soon on how to debug early boot issues in VMs or hardware using serial. Stay tuned.
Given the number of installations I do I've started to keep around preseed files; the text files used to configure automatic installations. I've made them available at http://people.canonical.com/~mtrudel/preseed/ so that they can be reused as necessary. Most of these preseed files make heavy use of the network to get the installation data and packages from the web, so they will need to be tweaked for use in an isolated network. They are annotated enough that it should be possible for anyone to improve on them to suit their own needs. I will add to these files as I run across things to test and automate. I hope we can use some of them soon in new automated QA tests where appropriate, so that it can help catch regressions.
For those not familiar with preseeding, these files can be used and referred to in the installation command-line when starting from a network PXE boot or a CDROM or pretty much any other installation medium. They are useful to tell the installer how you want the installation to be done without having to answer all of the individual questions one by one in the forms in ubiquity or debian-installer. The installer will read the preseed file and use these answers without showing the prompts. This also means some of the files I make available should not be used lightly, as they will happily wipe disks without asking. You've been warned :)
To use this, you'll want to specify "preseed/file=/path/to/file" (or just file=) for a file directly accessible as a file system or through TFTP, or "preseed/url=http://URI/to/file" (or just url=) if it's available using HTTP. On d-i installs, this means you may also need to add "auto=true priority=critical" to avoid having to fill in language settings and the like (since the preseeds are typically only read after language, country, and network have been configured); and on ubiquity installs (for example, using a CD), you'll want to add 'only-ubiquity automatic-ubiquity' to the kernel command-line, again to keep the automated, minimal look and feel.
I plan on writing another entry soon on how to debug early boot issues in VMs or hardware using serial. Stay tuned.
Tuesday, 21 January 2014
Call for testing: urfkill / Getting flight mode to rock on Ubuntu and Ubuntu Touch
Last month, I blogged about urfkill, and what it's meant to be used for.
The truth is, flight mode and proper killswitch (read: disabling radios on devices) handling is something that needs to happen on any device that deems itself "mobile". As such, it's one thing we need to look into for Ubuntu Touch.
I spent the last month or so working on improving urfkill. I've implemented better logging, a way to get debugging logs, flight mode (with patches from my friend Tony Espy), persistence, ...
At this point, urfkill seems to be in the proper state to make it, with the latest changes from the upstream git repository, into the distro. There is no formal release yet, but this is likely to happen very soon. So, I uploaded a git snapshot from the urfkill upstream repository into Trusty. It's now time to ask people to try it out, see how well it works on their systems, and just generally get to know how solid it is, and whether it's time to enable it on the desktop.
In time, it would be nice to replace the current implementation we have of killswitch persistence (saving and restoring the state of the "soft" killswitches) currently in two upstart jobs — rfkill-store and rfkill-restore — with urfkill as a first step, for the 14.04 release (and to handle flight mode on Touch, of course). In the end, my goal would be to achieve convergence on this particular aspect of the operating system sooner than later, since it's a relatively small part of the overall communications/networking picture.
So I call on everyone running Trusty to try to install the urfkill package, and file bugs or otherwise get me feedback on the software. :)
The truth is, flight mode and proper killswitch (read: disabling radios on devices) handling is something that needs to happen on any device that deems itself "mobile". As such, it's one thing we need to look into for Ubuntu Touch.
I spent the last month or so working on improving urfkill. I've implemented better logging, a way to get debugging logs, flight mode (with patches from my friend Tony Espy), persistence, ...
At this point, urfkill seems to be in the proper state to make it, with the latest changes from the upstream git repository, into the distro. There is no formal release yet, but this is likely to happen very soon. So, I uploaded a git snapshot from the urfkill upstream repository into Trusty. It's now time to ask people to try it out, see how well it works on their systems, and just generally get to know how solid it is, and whether it's time to enable it on the desktop.
In time, it would be nice to replace the current implementation we have of killswitch persistence (saving and restoring the state of the "soft" killswitches) currently in two upstart jobs — rfkill-store and rfkill-restore — with urfkill as a first step, for the 14.04 release (and to handle flight mode on Touch, of course). In the end, my goal would be to achieve convergence on this particular aspect of the operating system sooner than later, since it's a relatively small part of the overall communications/networking picture.
So I call on everyone running Trusty to try to install the urfkill package, and file bugs or otherwise get me feedback on the software. :)
Friday, 13 December 2013
urfkill : a daemon to centrally control RF killswitches
Here's another project of the u-daemon variety. The latest addition to upower, udev, etc. Meet urfkill.
urfkill is meant to be a daemon that centralizes killswitch handling, rather than having all kind of different applications and daemon handle Wi-Fi, Bluetooth, WWAN and whatnot separately, and potentially fighting over them, you can have just one system that tracks the states and makes it possible to switch just one type of killswitch on all at one, or turn everything off should you so desire...
One reason I've taken an interest in urfkill in Ubuntu is that as we build a phone, we have to keep thinking about how users of the devices will be mobile. That's even more the case when you think about a phone or tablet than a laptop: on a laptop, you may have to think of WiFi and Bluetooth, but you're just about as likely to have your laptop off or not have it at all; whereas phones and tablets have become ubiquitous in our way of life.
Like anyone, thinking mobile I'd first think of walking around, driving, or other methods of travel. Granted, nobody needs to turn off Wi-Fi when getting in their car, but what about on planes?
This is the first thing everything brings up when talking about killswitches. Planes. Alright, you really do need to turn the device off on take off and landing, but some airlines do now allow wifi to be on and offer in-flight service. They still require you to keep cellular and bluetooth off. Also, while I sometimes do take my laptop out of my bag on long flights, it's just cramped. Space is at a premium on a flight (hey, I fly economy...), you'll likely want to have a drink, people besides you may need to get up, spillage could occur if there is turbulence...
I don't really enjoy using my laptop on a flight, even though it's quite small. It's just so much trouble and not very comfortable.
However, I do love to watch saved movies, listen to music, and play games on a tablet. That tablet will most likely need to have radios turned off. My phone will typically just stay off and stowed far enough, since I don't really change SIM cards until I can do so safely without risking to lose the thing.
But then, one can also think of how you should avoid using transmitting equipment in a hospital. They have similar rules about radios as planes to avoid interfering with cardiac stimulators, MRI equipment, etc.
Having all kind of different applications handle each type of killswitches separately is quite risky and complicated. How are you certain that things have been turned off? How do you check in the UI whether it's the case? Can you see it quickly by scanning the screen?
What about the actual process of switching things off? Do you need to go through three different interfaces to toggle everything? What do you need to do if you don't have a physical switch to use?
What about persistence after a reboot?
urfkill is meant to, in time, address all such questions. At the moment, it still needs a lot of work though.
I've spent the last day fixing bugs I could find while testing urfkill on my laptop, as well as porting it to logind (still in progress). In time, we should be able to use it efficiently in Ubuntu to handle all the killswitches. With some more work, we will also be able to use it to manage the modem and other systems on Touch.
For the time being, urfkill is available in the archive, for those who want to start experimenting with it.
urfkill is meant to be a daemon that centralizes killswitch handling, rather than having all kind of different applications and daemon handle Wi-Fi, Bluetooth, WWAN and whatnot separately, and potentially fighting over them, you can have just one system that tracks the states and makes it possible to switch just one type of killswitch on all at one, or turn everything off should you so desire...
One reason I've taken an interest in urfkill in Ubuntu is that as we build a phone, we have to keep thinking about how users of the devices will be mobile. That's even more the case when you think about a phone or tablet than a laptop: on a laptop, you may have to think of WiFi and Bluetooth, but you're just about as likely to have your laptop off or not have it at all; whereas phones and tablets have become ubiquitous in our way of life.
Like anyone, thinking mobile I'd first think of walking around, driving, or other methods of travel. Granted, nobody needs to turn off Wi-Fi when getting in their car, but what about on planes?
This is the first thing everything brings up when talking about killswitches. Planes. Alright, you really do need to turn the device off on take off and landing, but some airlines do now allow wifi to be on and offer in-flight service. They still require you to keep cellular and bluetooth off. Also, while I sometimes do take my laptop out of my bag on long flights, it's just cramped. Space is at a premium on a flight (hey, I fly economy...), you'll likely want to have a drink, people besides you may need to get up, spillage could occur if there is turbulence...
I don't really enjoy using my laptop on a flight, even though it's quite small. It's just so much trouble and not very comfortable.
However, I do love to watch saved movies, listen to music, and play games on a tablet. That tablet will most likely need to have radios turned off. My phone will typically just stay off and stowed far enough, since I don't really change SIM cards until I can do so safely without risking to lose the thing.
But then, one can also think of how you should avoid using transmitting equipment in a hospital. They have similar rules about radios as planes to avoid interfering with cardiac stimulators, MRI equipment, etc.
Having all kind of different applications handle each type of killswitches separately is quite risky and complicated. How are you certain that things have been turned off? How do you check in the UI whether it's the case? Can you see it quickly by scanning the screen?
What about the actual process of switching things off? Do you need to go through three different interfaces to toggle everything? What do you need to do if you don't have a physical switch to use?
What about persistence after a reboot?
urfkill is meant to, in time, address all such questions. At the moment, it still needs a lot of work though.
I've spent the last day fixing bugs I could find while testing urfkill on my laptop, as well as porting it to logind (still in progress). In time, we should be able to use it efficiently in Ubuntu to handle all the killswitches. With some more work, we will also be able to use it to manage the modem and other systems on Touch.
For the time being, urfkill is available in the archive, for those who want to start experimenting with it.
Tuesday, 29 October 2013
Hacking with a Samsung ARM Chromebook on Trusty
So I decided it was about time to update / reinstall my Samsung Chromebook (the ARM one...) to Trusty, or at least to use Saucy. Turns out it's not that simple.
First, you need to know where to get the right stuff. I installed straight on the device, so chrUbuntu was the obvious choice. It's a pretty nice script that allows you to do just about anything necessary.
1) Bring your Chromebook to developer mode.
I'm not going to give the details. It's findable on the Internet, and unsafe enough that you should only do this if you know what you're doing... That counts double for running Trusty on the Samsung Chromebook.
From there, get into crosh (Ctrl+Alt+T), in shell mode (type shell at the crosh prompt).
2) Download the script:
3) Run the script:
This will do the gory install step, partition your device and format the new partition, download the ubuntu core tarball, and from there install the metapackage you've asked for as a first argument.
Be aware that if you have never repartitioned the device, you'll likely notice the system rebooting during the process -- if that happens, just re-run the same command to pick this back up where they ended. It's clear when the process is done and the system installed -- the script requires you to press Enter to reboot.
This was where things got fun.
Turns out my device booted fine into Trusty, but it would only show a black screen with the mouse cursor. If you moved the mouse, you could see the cursor changing but still nothing else. Switching to another VT (Ctrl-Alt-arrow (F1) or whatnot) would work to get you a text-mode login, but only if you switched early enough while X was getting ready to load... otherwise, you'd just get a pretty garbled display.
I hacked at the whole thing for a good while. I already know xf86-video-armsoc was involved in ChromeOS at some point, so I tried to install that.
Still no love. Tried to copy the libs from ChromeOS to the device, in case it was some libmali or EGL/GLES issue... Still nothing better.
I even touched /etc/X11/xorg.conf with some black magic, looking up the details using w3m in a text console...
Turns out the problem was with xf86-video-armsoc itself. I initially clued in when I looked at the dates for upload of the X packages and xf86-video-armsoc itself -- it didn't seem quite right: X was newer by a bit. I knew there could be some issue with the ABI in some cases; but after more careful investigation, that's probably fine too -- armsoc properly depends on -abi-14.
After much more work and trial and error, I updated xf86-video-armsoc to 0.6.0 from the Linaro git tree and also reverted one commit changing flags and it's not mostly working. X runs, I get lightdm, I can run apps -- "compositing" in Xubuntu works too, to get transparency and gradients... all with some minimal display corruption of the window decorations.
So the end of the line is -- if you want to run Trusty on your Chromebook and run into similar black screen issues, and you feel daring, feel free to try my newly-built xf86-video-armsoc package in my PPA:
https://launchpad.net/~mathieu-tl/+archive/ppa/+sourcepub/3627079/+listing-archive-extra
It's simple; once you're in a text console on the machine (login as user/user):
These updated packages, or at least some kind of permanent fix, should make it into Trusty soon. Stay tuned :)
First, you need to know where to get the right stuff. I installed straight on the device, so chrUbuntu was the obvious choice. It's a pretty nice script that allows you to do just about anything necessary.
1) Bring your Chromebook to developer mode.
I'm not going to give the details. It's findable on the Internet, and unsafe enough that you should only do this if you know what you're doing... That counts double for running Trusty on the Samsung Chromebook.
From there, get into crosh (Ctrl+Alt+T), in shell mode (type shell at the crosh prompt).
2) Download the script:
cd ~/Downloads
wget http://goo.gl/s9ryd
3) Run the script:
sudo bash s9ryd xubuntu-desktop dev
This will do the gory install step, partition your device and format the new partition, download the ubuntu core tarball, and from there install the metapackage you've asked for as a first argument.
Be aware that if you have never repartitioned the device, you'll likely notice the system rebooting during the process -- if that happens, just re-run the same command to pick this back up where they ended. It's clear when the process is done and the system installed -- the script requires you to press Enter to reboot.
This was where things got fun.
Turns out my device booted fine into Trusty, but it would only show a black screen with the mouse cursor. If you moved the mouse, you could see the cursor changing but still nothing else. Switching to another VT (Ctrl-Alt-arrow (F1) or whatnot) would work to get you a text-mode login, but only if you switched early enough while X was getting ready to load... otherwise, you'd just get a pretty garbled display.
I hacked at the whole thing for a good while. I already know xf86-video-armsoc was involved in ChromeOS at some point, so I tried to install that.
Still no love. Tried to copy the libs from ChromeOS to the device, in case it was some libmali or EGL/GLES issue... Still nothing better.
I even touched /etc/X11/xorg.conf with some black magic, looking up the details using w3m in a text console...
Turns out the problem was with xf86-video-armsoc itself. I initially clued in when I looked at the dates for upload of the X packages and xf86-video-armsoc itself -- it didn't seem quite right: X was newer by a bit. I knew there could be some issue with the ABI in some cases; but after more careful investigation, that's probably fine too -- armsoc properly depends on -abi-14.
After much more work and trial and error, I updated xf86-video-armsoc to 0.6.0 from the Linaro git tree and also reverted one commit changing flags and it's not mostly working. X runs, I get lightdm, I can run apps -- "compositing" in Xubuntu works too, to get transparency and gradients... all with some minimal display corruption of the window decorations.
So the end of the line is -- if you want to run Trusty on your Chromebook and run into similar black screen issues, and you feel daring, feel free to try my newly-built xf86-video-armsoc package in my PPA:
https://launchpad.net/~mathieu-tl/+archive/ppa/+sourcepub/3627079/+listing-archive-extra
It's simple; once you're in a text console on the machine (login as user/user):
nmcli dev wifi connect <your wifi network> password <your wifi password>
sudo add-apt-repository ppa:mathieu-tl/ppa
sudo apt-get update
sudo apt-get install xserver-xorg-video-armsoc-exynos
sudo reboot
These updated packages, or at least some kind of permanent fix, should make it into Trusty soon. Stay tuned :)
Thursday, 24 March 2011
Idea #27250: Auto eth0 isn't very user friendly. Many people wont know what it is.
The Problem
In case you didn't already figure it out, the title refers to a quite popular idea on Ubuntu Brainstorm. It also refers to a bug report against NetworkManager in Launchpad: bug #386900.
This is one issue I'd particularly like to solve soon. Although it most likely won't change for Natty (given that we're in Feature Freeze, and UI Freeze incessantly), I believe the question truly can be brought to a concensus and fixed early in the Oneiric cycle (and actually be made available upstream for everyone's benefit).
I think much of the issues coming from this bug report stem from diverging expectations of people who just care about their wired connection working and likely don't need to change it all that often, and people who actively use NetworkManager's connection profiles to achieve various things.
First, some background:
Why "Auto eth0" ?
The name "Auto eth0" comes from... well, the fact that it's a connection that was created automatically by NetworkManager with the simplest default settings (that is, just use DHCP to set an IP address), and the fact that it was created for the interface eth0. As such, people with multiple wired network cards would then get one "Auto XXXX" profile for each wired card. This profile should take care of 90% of all use cases, since most people will just want their system to be plugged in, their home router to hand over an IP address and be able to get online.
What's this with profiles ?
I just mentioned that the connection names shown are profiles. This is actually very important to me and quite a lot of people, because there are often cases where one would want to use specific network settings when at work and while at home. In other words, one could use "Auto eth0" at home with a simple setup, and benefit from a "At work" profile which sets a static IP address, or different DNS search strings (what would let your computer access "planet", instead of "planet.ubuntu.com" in Firefox, for instance).
Why so many issues ?
I guess this all falls apart when you consider that most people probably won't use alternate profiles for wired connections. DHCP tends to get most things right from the start, which make profiles not very useful unless you want to do very specific things with your connection.
Add to this the fact that not everyone knows that eth0 is what Linux calls your first wired network card (instead of say "Local Area Connection" as I believe it is on Windows), and you have a nice little mess to untangle.
Fixing all of this
I can't say I have all the answers. It's still unclear to me how much information is absolutely required, and I'm well aware that we can't really please everyone.
However, I've added a proposal to the brainstorm idea (Solution #7). It goes like this:
Lastly, drop the "Auto" from user-created wireless network profiles too. Since they are created by the user and carry the name of the wireless network, "Auto" is both unnecessary, and possibly incorrect (since people can change the settings after creating it).
I'd very much like anyone with an opinion on this to vote on Ubuntu Brainstorm for the idea they prefer, and comment with why my suggestion breaks things for them if it does. I certainly could have forgotten things. Comments on this blog are welcome too ;)
In case you didn't already figure it out, the title refers to a quite popular idea on Ubuntu Brainstorm. It also refers to a bug report against NetworkManager in Launchpad: bug #386900.
This is one issue I'd particularly like to solve soon. Although it most likely won't change for Natty (given that we're in Feature Freeze, and UI Freeze incessantly), I believe the question truly can be brought to a concensus and fixed early in the Oneiric cycle (and actually be made available upstream for everyone's benefit).
I think much of the issues coming from this bug report stem from diverging expectations of people who just care about their wired connection working and likely don't need to change it all that often, and people who actively use NetworkManager's connection profiles to achieve various things.
First, some background:
Why "Auto eth0" ?
The name "Auto eth0" comes from... well, the fact that it's a connection that was created automatically by NetworkManager with the simplest default settings (that is, just use DHCP to set an IP address), and the fact that it was created for the interface eth0. As such, people with multiple wired network cards would then get one "Auto XXXX" profile for each wired card. This profile should take care of 90% of all use cases, since most people will just want their system to be plugged in, their home router to hand over an IP address and be able to get online.
What's this with profiles ?
I just mentioned that the connection names shown are profiles. This is actually very important to me and quite a lot of people, because there are often cases where one would want to use specific network settings when at work and while at home. In other words, one could use "Auto eth0" at home with a simple setup, and benefit from a "At work" profile which sets a static IP address, or different DNS search strings (what would let your computer access "planet", instead of "planet.ubuntu.com" in Firefox, for instance).
Why so many issues ?
I guess this all falls apart when you consider that most people probably won't use alternate profiles for wired connections. DHCP tends to get most things right from the start, which make profiles not very useful unless you want to do very specific things with your connection.
Add to this the fact that not everyone knows that eth0 is what Linux calls your first wired network card (instead of say "Local Area Connection" as I believe it is on Windows), and you have a nice little mess to untangle.
Fixing all of this
I can't say I have all the answers. It's still unclear to me how much information is absolutely required, and I'm well aware that we can't really please everyone.
However, I've added a proposal to the brainstorm idea (Solution #7). It goes like this:
I'm suggesting the name of the profile to be something like "Default". It should not be tied to any particular adapter.Furthermore, perhaps items in the network menu shouldn't list the full details of the network card (it's full name from udev as it does now). Instead, the interface name would be sufficient. I expect people who use multiple cards to know what eth0 and eth1 mean and refer to.
This way, any new connection use that profile which will have default settings to use DHCP and the usual (as Auto eth0 is set). All adapters could share it, so adding a new interface to a computer would still just "work".
For notifications, I suggest the following changes:
- The title should mention "Wired network", and probably the same of the interface (eth0 in most cases).
- The text of the notification should say:
Connection established, using profile "Default"
or whatever profile in use.
Lastly, drop the "Auto" from user-created wireless network profiles too. Since they are created by the user and carry the name of the wireless network, "Auto" is both unnecessary, and possibly incorrect (since people can change the settings after creating it).
I'd very much like anyone with an opinion on this to vote on Ubuntu Brainstorm for the idea they prefer, and comment with why my suggestion breaks things for them if it does. I certainly could have forgotten things. Comments on this blog are welcome too ;)
Wednesday, 9 March 2011
This weekend's GeekFest in Montreal
We had a table at this weekend's GeekFest geek festival in Montreal. It was awesome! Tons of people, and even better, tons of interest about Ubuntu and our LoCo team.
We gave out CDs, stickers, some extra FSF stickers I had in my backpack, and generally told people all they wanted to know about Ubuntu, gaming on Ubuntu (we had a demo of World of Goo running on one of the laptops for a good part of Sunday), and the Ubuntu Quebec LoCo team. It was very interesting to hear people tell us they already knew about Ubuntu or used it at home, at work, etc; yet still didn't know about the local community team and the help resources we offer.
One of the things we focused on was how Ubuntu Quebec has a mailing list and forum to provide help, announce events and just generally discuss things, as well as our IRC channel on Freenode (#ubuntu-qc, for those who don't know!). Lots of people were surprised to hear of a user group for Ubuntu but very interested by it. I printed and gave out nearly 40 business cards with contact information for the LoCo team.
I am very happy to have been helped by two very active members of the team: Christian Parent (Mobidoy) and Philippe Gauthier (deuxpi), and joined on Sunday by Eric Beaurivage (sipherdee), another LoCo team member. Without them, we certainly couldn't have been able to speak to so many people, and we definitely wouldn't have had any time to visit the other kiosks (can't just stay sitting... if you hold a kiosk in a conference, just got to go see the other things!).
Christian always has very cool ideas, this weekend it was to show his new laptop sticker (a mouse pad glued to the laptop).
Some other interesting aspects:
To our right was the kiosk of devLAB, a project to start programming contests, identify new technologies, etc... Did I get this all right? Sure hope so. The great thing too is that they were interested by our Global Jam ideas, so there may be collaboration on that aspect to come for this cycle's Global Jam event in Montreal. That still needs to be discussed on the mailing list.
We met with someone from Foonzo Café, a new café in Montreal near Peel metro which runs all their systems on Ubuntu! They have some 80 seated places, so we may consider holding the Montreal release party there for Natty. Check how the discussion unfolds for this on our mailing list.
And last but not least, we met with Carlos and his brother who started "Carlito's Contraptions". They work on Nao the robot to develop applications, have it do stuff... While Nao doesn't exactly run Ubuntu (it's really a stripped down Linux with the bare minimum), their development systems are Ubuntu. They were nice enough to allow us to take action shots of Nao with a Ubuntu logo sticker. First it was on a GeekFest pin attached to Nao with sticky-tack, then they put another sticker directly on Nao's right arm. Rock on guys!
Take a look at all the pictures on my Picasa Album: "GeekFestMtl 2011".
We gave out CDs, stickers, some extra FSF stickers I had in my backpack, and generally told people all they wanted to know about Ubuntu, gaming on Ubuntu (we had a demo of World of Goo running on one of the laptops for a good part of Sunday), and the Ubuntu Quebec LoCo team. It was very interesting to hear people tell us they already knew about Ubuntu or used it at home, at work, etc; yet still didn't know about the local community team and the help resources we offer.
One of the things we focused on was how Ubuntu Quebec has a mailing list and forum to provide help, announce events and just generally discuss things, as well as our IRC channel on Freenode (#ubuntu-qc, for those who don't know!). Lots of people were surprised to hear of a user group for Ubuntu but very interested by it. I printed and gave out nearly 40 business cards with contact information for the LoCo team.
I am very happy to have been helped by two very active members of the team: Christian Parent (Mobidoy) and Philippe Gauthier (deuxpi), and joined on Sunday by Eric Beaurivage (sipherdee), another LoCo team member. Without them, we certainly couldn't have been able to speak to so many people, and we definitely wouldn't have had any time to visit the other kiosks (can't just stay sitting... if you hold a kiosk in a conference, just got to go see the other things!).
Christian always has very cool ideas, this weekend it was to show his new laptop sticker (a mouse pad glued to the laptop).
Some other interesting aspects:
To our right was the kiosk of devLAB, a project to start programming contests, identify new technologies, etc... Did I get this all right? Sure hope so. The great thing too is that they were interested by our Global Jam ideas, so there may be collaboration on that aspect to come for this cycle's Global Jam event in Montreal. That still needs to be discussed on the mailing list.
We met with someone from Foonzo Café, a new café in Montreal near Peel metro which runs all their systems on Ubuntu! They have some 80 seated places, so we may consider holding the Montreal release party there for Natty. Check how the discussion unfolds for this on our mailing list.
Take a look at all the pictures on my Picasa Album: "GeekFestMtl 2011".
Tuesday, 27 April 2010
You're invited: Montreal Lucid Lynx release party!
The Ubuntu-Quebec team is having a party here in Montreal (and in other cities too!!!) once more, this time to celebrate the release of Lucid Lynx. This will once again be held at the Bar Le Saint-Sulpice:
Bar Le Saint-Sulpice
1680, Saint-Denis,
Montréal, Québec,
H2X3K6,
514 844-9458
Everyone's invited to join us there this Thursday, April 29th.
Lots of people have already either RSVP'd using the wonderful LoCo Directory event pages, and many others have confirmed their presence already...
There's going to be a couple of other parties going on this time in the province: another one in Montreal on May 20th, Dummondville and Quebec city on the 5th and 6th of May; if you want to know more, don't hesitate to visit our wiki page for the Lucid release parties organized by Ubuntu-Quebec: https://wiki.ubuntu.com/QuebecTeam/LucidParty
Join us and have a chance to meet other Ubuntu enthusiasts like you :)
Bar Le Saint-Sulpice
1680, Saint-Denis,
Montréal, Québec,
H2X3K6,
514 844-9458
Everyone's invited to join us there this Thursday, April 29th.
Lots of people have already either RSVP'd using the wonderful LoCo Directory event pages, and many others have confirmed their presence already...
There's going to be a couple of other parties going on this time in the province: another one in Montreal on May 20th, Dummondville and Quebec city on the 5th and 6th of May; if you want to know more, don't hesitate to visit our wiki page for the Lucid release parties organized by Ubuntu-Quebec: https://wiki.ubuntu.com/QuebecTeam/LucidParty
Join us and have a chance to meet other Ubuntu enthusiasts like you :)
Wednesday, 10 December 2008
De vieilles nouvelles, mais quand même...
Bon, j'avoue, c'est pas du nouveau. J'ai juste pas entendu parler de ca auparavant, et je pense que c'est quand même un bon truc à savoir.
Ici, au Québec, le gouvernement accordait directement à Microsoft, sans appel d'offres, des contrats logiciels. Deux organismes/entreprises se sont réveillés, soit l'organisme FACIL et l'entreprise Savoir-Faire Linux, pour amener un cour le gouvernement sur ce point et les réveiller un peu.
http://facil.qc.ca/fr/media/20080827-facil-conteste-les-pratiques-gouvernementales
http://www.qctop.com/actualites/logiciel-libre-cour-gouv-qc.htm
Je n'irai pas dans les détails puisqu'ils sont lisibles dans les liens ci-haut, mais c'est un excellent point à apporter, d'autant plus que le gouvernement devrait encourager l'industrie informatique locale...
Sur un autre point tout aussi "vieux" comme nouvelles, il existe un pacte signée par les députés de différents partis sur le support du logiciel libre. D'un certain côté, c'est très bien que plusieurs députés l'aient déjà signée, mais c'est quand même triste de constater que la majorités sont soit du Parti Vert, soit de Québec Solidaire. Les autres devraient peut-être se réveiller un peu... Le lien est ici: http://facil.qc.ca/fr/PacteduLogicielLibre
Il y a également une pétition, accessible à tous, pour l'utilisation du logiciel libre par le gouvernement du Québec.
Ceci dit, visitez le site de la pétition, signez-là, et tentez d'en parler avec votre député et de l'amener à la signer, ainsi que le Pacte du Logiciel Libre!
Ici, au Québec, le gouvernement accordait directement à Microsoft, sans appel d'offres, des contrats logiciels. Deux organismes/entreprises se sont réveillés, soit l'organisme FACIL et l'entreprise Savoir-Faire Linux, pour amener un cour le gouvernement sur ce point et les réveiller un peu.
http://facil.qc.ca/fr/media/20080827-facil-conteste-les-pratiques-gouvernementales
http://www.qctop.com/actualites/logiciel-libre-cour-gouv-qc.htm
Je n'irai pas dans les détails puisqu'ils sont lisibles dans les liens ci-haut, mais c'est un excellent point à apporter, d'autant plus que le gouvernement devrait encourager l'industrie informatique locale...
Sur un autre point tout aussi "vieux" comme nouvelles, il existe un pacte signée par les députés de différents partis sur le support du logiciel libre. D'un certain côté, c'est très bien que plusieurs députés l'aient déjà signée, mais c'est quand même triste de constater que la majorités sont soit du Parti Vert, soit de Québec Solidaire. Les autres devraient peut-être se réveiller un peu... Le lien est ici: http://facil.qc.ca/fr/PacteduLogicielLibre
Il y a également une pétition, accessible à tous, pour l'utilisation du logiciel libre par le gouvernement du Québec.
Ceci dit, visitez le site de la pétition, signez-là, et tentez d'en parler avec votre député et de l'amener à la signer, ainsi que le Pacte du Logiciel Libre!
Wednesday, 26 November 2008
Un nouveau blog?
Intéressant. Le CTO de la compagnie où je travaille vient de lancer un nouveau blog. C'est pas mal, reste à voir si il y aura des mises à jour...
En tout cas, c'est certainement un pas dans la bonne direction, si on peut avoir davantage de détails sur les idées des hauts dirigeants de l'entreprise, sur leurs perspectives de la situation économique, et de ce qui se passe du côté de la direction générale que prend l'entreprise. Le blog n'est pas public, seulement accessible (du moins pour le moment), aux employés via un site Intranet. Ca m'a fait un peu penser aux weblogs, par exemple, de Mark Shuttleworth (CEO de Canonical) ou Jonathan Schwarz (CEO de Sun), qui ont aussi des weblogs, pour ne nommer que ceux que j'ai bel et bien lus.
Ce qui me surprendrais, mais me donnerais vraiment un boost de motivation par contre, ce serait de voir qu'on a un "militant" du logiciel libre parmis la direction, ou la haute direction... Ceci dit, je suis pratiquement certain que ce n'est pas le cas. :)
En tout cas, c'est certainement un pas dans la bonne direction, si on peut avoir davantage de détails sur les idées des hauts dirigeants de l'entreprise, sur leurs perspectives de la situation économique, et de ce qui se passe du côté de la direction générale que prend l'entreprise. Le blog n'est pas public, seulement accessible (du moins pour le moment), aux employés via un site Intranet. Ca m'a fait un peu penser aux weblogs, par exemple, de Mark Shuttleworth (CEO de Canonical) ou Jonathan Schwarz (CEO de Sun), qui ont aussi des weblogs, pour ne nommer que ceux que j'ai bel et bien lus.
Ce qui me surprendrais, mais me donnerais vraiment un boost de motivation par contre, ce serait de voir qu'on a un "militant" du logiciel libre parmis la direction, ou la haute direction... Ceci dit, je suis pratiquement certain que ce n'est pas le cas. :)
Subscribe to:
Posts (Atom)