Linux

Costales: UbuCon Europe 2018: Analysing a dream [English|Spanish]

Planet Ubuntu - 12 hours 34 min ago
UbuCon Europe 2018: Analysing a dream (English)
The idea of organising the Ubucon in Xixon, Asturies was set two years ago, while participating in the European Ubucon in Essen (germany). The Paris Ubucon took place and in those days we uderstood that there was a group enough of people with the capacities and the will to hold an European Congress for Ubuntu lovers. We had learnt a lot from German and French colleagues thanks to their respective amazing organizations and, at the same time, our handicap was the lack of s consolidated group in Spain.

Asturies


The first task was to bring together a group of people big enough and with the motivation of working together both in preparation and the development of activities during the three main days of the Ubucon. Eleven volunteers responded to the call of Marcos costales, creating a telegram group where two main decisions were taken:
  • Chosen city, Xixon
  • Date, coinciding with the release of Ubuntu 18.04

2

A particular building was selected for the Ubucon. The "Antiguo instituto Jovellanos" had everything we needed: perfect location in the center of the city, big conference room for 100 people, inner courtyard and the availability of several extra rooms in case we had more and more speakers.

3
We made our move and offered Spain as a potential host for the next UbuCon Europd. We knew that the idea was floating in the minds of our portuguese and british colleagues but someway, he had the feeling that it was our moment to take the risk and we did. Considering that there is no European Organisation for Ubuntu (although it is getting close), we tacitly recevied the honor of being in charge of the European Ubucon 2018. Then , the long process of making a dream come true began.
4
The organization was simple and even simpler. Pivoting on Marcos as the main responsible, we organized several groups in Telegram: communication, organization....and we began to give publicity to the event.The gathering of attendees was done through the website http://ubucon.eu where after a first press release that some important blogs of Ubuntu in Spanish spread, we received an avalanche of registrations (more than 100 in the first days) that made us fear for our capacity of reception and that on the other hand allowed us to take the pulse of the interest aroused.
We created a GMail account to manage communications, reused existing European UbuCon accounts on Twitter and Google+ and created a Facebook account managed by our friend Diogo Constantino from Portugal, to give information to everyone on social networks.We used Telegram to create an information channel (205 members) and two groups, one for attendees (68 members) and one for speakers (31 members).Suddenly it seemed to us that the creature was growing and growing, even above our expectations. We had to ask for institutional support and we got it.
The Municipal Foundation of Culture and Education of Xixón gave us the Old Jovellanos Institute. The Gijón Congress Office provided us with contacts and discounts on bus and train transport (ALSA and RENFE).Canonical helped us financially by paying the insurance that covered our possible accident liabilities and the small costs of auxiliary material. Nathan Haines, Marius Quabeck and Ubuntu FR provided us with tablecloths for the tables.Slimbook provided us with laptops for each of the conference rooms and for the reception of attendees.
5
At the time, with our dream growing in the wishing oven like a huge cake, it seemed to us that we needed legal protection in the form of a partnership and we tried. We live in a big old country that is not agile for these things and besides the difficulty of bringing together people from Alicante, Andalusia, Asturias, the Balearic Islands, Barcelona, León and Madrid we were put ahead of the administration and it was not possible.Speaking of the dispersion of the organizers. How did we coordinate? Telegram has been the main axis. EtherPad is used to build documents collaboratively. Mumble (hosted on a Raspberry PI) for coordination meetings, Drive for documents and records of attendees and speakers and MailChimp for bulk mailings.

6
So it was time to ask for speakers and then what was already overflowing became a real luxury. We began to receive requests for talks from individuals and businesses and there were weeks when we had to meet every other day to decide on approvals.  Finally we had 37 talks, conferences, workshop and 6 stands, 3 podcasts broadcasting in Spanish, Portuguese and German. On Saturday the 28th we had to provide up to 4 spaces at a time to accommodate everyone.
7
An Ubucon Europe must have at least three objectives to achieve:
  1. Sharing knowledge
  2. Bring Europeans together around Ubuntu, strengthen bonds of friendship
  3. Have fun
8

To achieve the third objective we had the best possible host. Marcos was in his hometown and had all the elements to make the hours of living together and having fun unique. We knew it was very important that social events be close to each other. Xixon is a city with an ideal size for this to happen and so they organized themselves. Focused on Saturday's spicha, which was attended by 87 people, the rest of the days we had a complete program that allowed those who did not know Spain, and Asturias in particular, to touch the sky of a tremendously welcoming land with their fingers. Live music in the Trisquel, drinks and disco by the sea, cider and Asturian gastronomy in the Poniente beach and cultural visits... Could you ask for more?

9
10

And the dream came true, on Friday 27th April Ubucon Europe 2018 was inaugurated. All the scheduled events were on schedule and the staff of 8 people attended as well as we knew the reception of the event as well as the logistics of the up to 4 simultaneous rooms that we needed at some point. Without incident, 140 attendees were able to listen to some of the 37 talks, more than 350 messages were published on Twitter, hundreds of posts on Google + and Facebok and we spent 474 € on the small expenses of the organization, which have possibly provided the city with 40,000 € of profit between hotels, restaurants, transport.... The social events were a success and the group of participants/speakers stayed together for three days.We're proud of you. We can't always make our dreams come true.
11
And that all, folks. See you next time!



UbuCon Europe 2018: Análisis de un sueño (Spanish)
La organización de la Ubucon en Xixón se empezó a gestar dos años antes, mientras participábamos en Alemania en la Ubucon Europea de Essen, luego vino París y para esas fechas empezamos a entender que había un grupo suficiente de personas con capacidad de organización y con  voluntad de llevar a cabo un congreso europeo de amantes de Ubuntu. Habíamos aprendido de alemanes y franceses con organizaciones fantásticas y sin embargo teníamos en nuestra contra la inexistencia de un equipo consolidado en España.
12
Lo primero fue reunir a un número suficiente de personas dispuestas a trabajar, tanto en la preparación como en el desarrollo de los tres días. A la convocactoria de Marcos Costales nos apuntamos 11 personas reunidas en un grupo de Telegram que tomamos las primeras decisiones:
  •     La ciudad elegida, Xixón
  •     Las fechas coincidentes con la salida de Ubuntu 18.04

Conseguimos un edificio singular para la celebración. El antiguo Instituto Jovellanos tenía todo lo que necesitábamos: estaba en un lugar céntrico de la ciudad, tenía un salón de actos para más de 100 personas, un patio para montar stands y la posibilidad de utilizar distintas aulas según fuéramos consiguiendo más conferenciantes.

13

Nos decidimos y nos postulamos como país anfitrión. Sabíamos que la idea rondaba entre portugueses y británicos, pero de alguna manera teníamos la sensación de que era nuestro momento para lanzarnos a la piscina y así lo hicimos y dado que hasta ahora no existe ninguna organización europea de Ubuntu (aunque ya está cerca) de una manera tácita se nos otorgó el honor de hacernos cargo de la Ubucon Europea de 2018 y entonces empezó la carrera por hacer realidad un sueño.
14
La organización fue sencilla y aun se simplificó más. Pivotando sobre Marcos como responsable pincipal, organizamos en Telegram varios grupos: comunicación, organización....y empezamos a dar publicidad al evento.La recogida de asistentes se hizo a través de la página web http://ubucon.eu donde tras un primer comunicado de prensa que difundieron algunos blogs importantes de Ubuntu en español, recibimos una avalancha de inscripciones (más de 100 en los primeros días) que nos hizo temer por nuestra capacidad de acogida y que por otro lado nos permitió ir tomando el pulso al interés suscitado.
Creamos una cuentra de GMail para administrar las comunicaciones, reutilizamos las cuentas existentes de la UbuCon europea en Twitter y Google+ y creamos una de Facebook que administró nuestro amigo Diogo Constantino de Portugal, para dar información a todo el mundo en redes sociales.Usamos Telegram para crear un canal de información (205 miembros) y dos grupos, uno para asistentes (68 miembros) y otro para conferenciantes (31 miembros).De pronto nos pareció que la criatura crecía y crecía, incluso por encima de nuestras espectativas. Tuvimos que pedir apoyo institucional y lo conseguimos.
La Fundación Municipal de Cultura y Educación de Xixón nos cedió el Antiguo Instituto Jovellanos. La Oficina de Congresos de Gijón nos facilitó contactos y descuentos en transporte de autobús y tren (ALSA y RENFE).Canonical nos ayudó económicamente pagando el seguro que cubría nuestras posibles responsabilidades por accidentes y los pequeños costes de material auxiliar. Nathan Haines, Marius Quabeck y Ubuntu FR nos facilitaron manteles para las mesas.Slimbook nos facilitó portátiles para cada una de las salas de conferencia y para la recepción de asistentes.
En aquel momento, con nuestro sueño creciendo en el horno de los deseos como un enorme bizcocho, nos pareció que necesitábamos un amparo legal en forma de asociación y lo intentamos. Vivimos en un país grande y viejo que no es ágil para estas cosas y además de la dificultad de reunir a personas de Alicante, Andalucía, Asturias, Baleares, Barcelona, León y Madrid se nos puso por delante la administración y no fue posible.Hablando de la dispersión de los organizadores. ¿Cómo nos coordinábamos? Telegram ha sido el eje principal. EtherPad  lo usamos para construir documentos de manera colaborativa. Mumble (alojado en una Raspberry PI) para las reuniones de coordinación, Drive para los documentos y registros de asistentes y conferenciantes y MailChimp para el envío de correos masivos.
15
Así las cosas llegó el momento de pedir conferenciantes y entonces lo que ya estaba siendo un desborde empezó a ser realmente un lujo. Empezamos a recibir peticiones de charlas por parte de particulares y empresas y hubo semanas en las que cada dos días teníamos que reunirnos para decidir las aprobaciones.  Finalmente tuvimos 37 charlas, conferencias, workshop y 6 stands, 3 podcasts emitiendo en español, portugués y alemán. El sábado 28 tuvimos que habilitar hasta 4 espacios a la vez para albergar a todo el mundo.
16
Una Ubucon Europe debe tener al menos tres objetivos a cumplir:
  1.     Compartir conocimiento
  1.     Reunir a los europeos en torno a Ubuntu, reforzar lazos de amistad
  1.     Divertirse

Para conseguir el tercer objetivo contábamos con el mejor anfitrión posible. Marcos estaba en su ciudad y tenía todos los mimbres para que las horas de convivencia y diversión fuesen únicas. Sabíamos que era muy importante que los eventos sociales estuvieran cerca unos de otros. Xixón es una ciudad con un tamaño ideal para que esto ocurriera y así se organizaron. Centrados en la espicha del sábado a la que asistieron 87 personas, el resto de los días tuvimos un programa completo que permitió a quienes no conocian España, y Asturias en particular tocar con los dedos el cielo de una tierra tremendamente acogedora. Música en vivo en el Trisquel, copas y disco junto al mar, sidra y gastronomia asturiana en la Playa de Poniente y visitas culturales...¿Se podía pedir más?

17
Y el sueño se hizo realidad, el viernes 27 de Abril se inauguró la Ubucon Europe 2018. Todos los actos programados cumplieron con los horarios previstos y el staff de 8 personas atendimos tan bien como supimos la recepción del evento así como la logística de las hasta 4 salas simultáneas que en algún momento necesitamos. Sin incidentes, 140 asistentes pudieron escuchar alguna de las 37 charlas, se publicaron más de 350 mesajes en Twitter, cientos de post en Google + y Facebok y empleamos 474 € en los pequeños gastos de la organización, que posiblemente hayan proporcionado a la ciudad unos 40.000 € de beneficio entre hoteles, restaurantes, transporte... Los actos sociales fueron un éxito y el grupo de participantes/conferenciantes se mantuvo unido los tres días.Estamos orgullosos. No siempre podemos hacer realidad nuestros sueños.

18
Y esto ha sido todo. ¡Nos vemos en la siguiente!
19
UbuCon Europe 2018 | Made with ❤ by:
  • Fco. Javier Teruelo de Luis
  • Sergi Quiles Pérez
  • Francisco Molinero
  • Santiago Moreira
    • Antonio Fernandes
    • Paul Hodgetts
    • Joan CiberSheep
    • Fernando Lanero
    • Manu Cogolludo
    • Marcos Costales

    20
    Text redaction by Paco Molinero. Translation by Santiago Moreira.


    More pictures:
      https://www.flickr.com/groups/4493690@N20/pool/The conferences:
      https://www.dropbox.com/s/omnivzemd6hu5uc/UbuCon%20Europe%202018%20presentations.zip?dl=0
    Categories: Linux

    Sina Mashek: Check if external ip has changed

    Planet Ubuntu - Fri, 05/18/2018 - 15:00

    Sometimes we are on connections that have a dynamic ip. This will add your current external ip to ~/.external-ip.

    Each time the script is run, it will dig an OpenDNS resolver to grab your external ip. If it is different from what is in ~/.external-ip it will echo the new ip. Otherwise it will return nothing.

    #!/bin/sh # Check external IP for change # Ideal for use in a cron job # # Usage: sh check-ext-ip.sh # # Returns: Nothing if the IP is same, or the new IP address # First run always returns current address # # Requires dig: # Debian/Ubuntu: apt install dnsutils # Solus: eopkg install bind-utils # CentOS/Fedora: yum install bind-utils # # by Sina Mashek <sina@sinacutie.stream> # Released under CC0 or Public Domain, whichever is supported # Where we will store the external IP EXT_IP="$HOME/.external-ip" # Check if dig is installed if [ "$(command -v dig)" = "" ]; then echo "This script requires 'dig' to run" # Load distribution release information . /etc/os-release # Check for supported release; set proper package manager and package name if [ "$ID" = "debian" ] || [ "$ID" = "ubuntu" ]; then MGR="apt" PKG="dnsutils" elif [ "$ID" = "fedora" ] || [ "$ID" = "centos" ]; then MGR="yum" PKG="bind-utils" elif [ "$ID" = "solus" ]; then MGR="eopkg" PKG="bind-utils" else echo "Please consult your package manager for the correct package" exit 1 fi # Will run if one of the above supported distributions was found echo "Installing $PKG ..." sudo "$MGR" install "$PKG" fi # We check our external IP directly from a DNS request GET_IP="$(dig +short myip.opendns.com @resolver1.opendns.com)" # Check if ~/.external-ip exists if [ -f "$EXT_IP" ]; then # If the external ip is the same as the current ip if [ "$(cat "$EXT_IP")" = "$GET_IP" ]; then exit 0 fi # If it doesn't exist or is not the same, grab and save the current IP else echo "$GET_IP" > "$EXT_IP" fi
    Categories: Linux

    Sina Mashek: Check if external ip has changed

    Planet Ubuntu - Fri, 05/18/2018 - 15:00

    Sometimes we are on connections that have a dynamic ip. This will add your current external ip to ~/.external-ip.

    Each time the script is run, it will dig an OpenDNS resolver to grab your external ip. If it is different from what is in ~/.external-ip it will echo the new ip. Otherwise it will return nothing.

    #!/bin/sh # Check external IP for change # Ideal for use in a cron job # # Usage: sh check-ext-ip.sh # # Returns: Nothing if the IP is same, or the new IP address # First run always returns current address # # Requires dig: # Debian/Ubuntu: apt install dnsutils # Solus: eopkg install bind-utils # CentOS/Fedora: yum install bind-utils # # by Sina Mashek <sina@sinacutie.stream> # Released under CC0 or Public Domain, whichever is supported # Where we will store the external IP EXT_IP="$HOME/.external-ip" # Check if dig is installed if [ "$(command -v dig)" = "" ]; then echo "This script requires 'dig' to run" # Load distribution release information . /etc/os-release # Check for supported release; set proper package manager and package name if [ "$ID" = "debian" ] || [ "$ID" = "ubuntu" ]; then MGR="apt" PKG="dnsutils" elif [ "$ID" = "fedora" ] || [ "$ID" = "centos" ]; then MGR="yum" PKG="bind-utils" elif [ "$ID" = "solus" ]; then MGR="eopkg" PKG="bind-utils" else echo "Please consult your package manager for the correct package" exit 1 fi # Will run if one of the above supported distributions was found echo "Installing $PKG ..." sudo "$MGR" install "$PKG" fi # We check our external IP directly from a DNS request GET_IP="$(dig +short myip.opendns.com @resolver1.opendns.com)" # Check if ~/.external-ip exists if [ -f "$EXT_IP" ]; then # If the external ip is the same as the current ip if [ "$(cat "$EXT_IP")" = "$GET_IP" ]; then exit 0 fi # If it doesn't exist or is not the same, grab and save the current IP else echo "$GET_IP" > "$EXT_IP" fi
    Categories: Linux

    Marco Trevisan (Treviño): Hello Planet GNOME!

    Planet Ubuntu - Fri, 05/18/2018 - 09:46

    Hey guys, although I’ve been around for a while hidden in the patches, some months ago (already!?!) I did my application to join the GNOME Foundation, and few days after – thanks to some anonymous votes – I got approved :), and thus I’m officially part of the family!

    So, thanks again, and sorry for my late “hello”

    Categories: Linux

    Ubuntu Podcast from the UK LoCo: S11E11 – Station Eleven - Ubuntu Podcast

    Planet Ubuntu - Fri, 05/18/2018 - 05:54

    This week we reconstruct a bathroom and join the wireless gaming revolution. We discuss the Steam Link app for Android and iOS, the accessible Microsoft Xbox controller, Linux applications coming to ChromeOS and round up the community news.

    It’s Season 11 Episode 11 of the Ubuntu Podcast! Alan Pope, Mark Johnson and Martin Wimpress are connected and speaking to your brain.

    In this week’s show:

    That’s all for this week! You can listen to the Ubuntu Podcast back catalogue on YouTube. If there’s a topic you’d like us to discuss, or you have any feedback on previous shows, please send your comments and suggestions to show@ubuntupodcast.org or Tweet us or Comment on our Facebook page or comment on our Google+ page or comment on our sub-Reddit.

    Categories: Linux

    Mathieu Trudel: Building a local testing lab with Ubuntu, MAAS and netplan

    Planet Ubuntu - Wed, 05/16/2018 - 16:47
    OverviewI'm presenting here the technical aspects of setting up a small-scale testing lab in my basement, using as little hardware as possible, and keeping costs to a minimum. For one thing, systems needed to be mobile if possible, easy to replace, and as flexible as possible to support various testing scenarios. I may wish to bring part of this network with me on short trips to give a talk, for example.

    One of the core aspects of this lab is its use of the network. I have former experience with Cisco hardware, so I picked some relatively cheap devices off eBay: a decent layer 3 switch (Cisco C3750, 24 ports, with PoE support in case I'd want to start using that), a small Cisco ASA 5505 to act as a router. The router's configuration is basic, just enough to make sure this lab can be isolated behind a firewall, and have an IP on all networks. The switch's config is even simpler, and consists in setting up VLANs for each segment of the lab (different networks for different things). It connects infrastructure (the MAAS server, other systems that just need to always be up) via 802.1q trunks; the servers are configured with IPs on each appropriate VLAN. VLAN 1 is my "normal" home network, so that things will work correctly even when not supporting VLANs (which means VLAN 1 is set to the the native VLAN and to be untagged wherever appropriate). VLAN 10 is "staging", for use with my own custom boot server. VLAN 15 is "sandbox" for use with MAAS. The switch is only powered on when necessary, to save on electricity costs and to avoid hearing its whine (since I work in the same room). This means it is usually powered off, as the ASA already provides many ethernet ports. The telco rack in use was salvaged, and so were most brackets, except for the specialized bracket for the ASA which was bought separately. Total costs for this setup is estimated to about 500$, since everything comes from cheap eBay listings or salvaged, reused equipment.

    The Cisco hardware was specifically selected because I had prior experience with them, so I could make sure the features I wanted were supported: VLANs, basic routing, and logs I can make sense of. Any hardware could do -- VLANs aren't absolutely required, but given many network ports on a switch, it tends to avoid requiring multiple switches instead.

    My main DNS / DHCP / boot server is a raspberry pi 2. It serves both the home network and the staging network. DNS is set up such that the home network can resolve any names on any of the networks: using home.example.com or staging.example.com, or even maas.example.com as a domain name following the name of the system. Name resolution for the maas.example.com domain is forwarded to the MAAS server. More on all of this later.

    The MAAS server has been set up on an old Thinkpad X230 (my former work laptop); I've been routinely using it (and reinstalling it) for various tests, but that meant reinstalling often, possibly conflicting with other projects if I tried to test more than one thing at a time. It was repurposed to just run Ubuntu 18.04, with a MAAS region and rack controller installed, along with libvirt (qemu) available over the network to remotely start virtual machines. It is connected to both VLAN 10 and VLAN 15.

    Additional testing hardware can be attached to either VLAN 10 or VLAN 15 as appropriate -- the C3750 is configured so "top" ports are in VLAN 10, and "bottom" ports are in VLAN 15, for convenience. The first four ports are configured as trunk ports if necessary. I do use a Dell Vostro V130 and a generic Acer Aspire laptop for testing "on hardware". They are connected to the switch only when needed.

    Finally, "clients" for the lab may be connected anywhere (but are likely to be on the "home" network). They are able to reach the MAAS web UI directly, or can use MAAS CLI or any other features to deploy systems from the MAAS servers' libvirt installation.

    Setting up the network hardwareI will avoid going into the details of the Cisco hardware too much; configuration is specific to this hardware. The ASA has a restrictive firewall that blocks off most things, and allows SSH and HTTP access. Things that need access the internet go through the MAAS internal proxy.

    For simplicity, the ASA is always .1 in any subnet, the switch is .2 when it is required (and was made accessible over serial cable from the MAAS server). The rasberrypi is always .5, and the MAAS server is always .25. DHCP ranges were designed to reserve anything .25 and below for static assignments on the staging and sandbox networks, and since I use a /23 subnet for home, half is for static assignments, and the other half is for DHCP there.

    MAAS server hardware setupNetplan is used to configure the network on Ubuntu systems. The MAAS server's configuration looks like this:

    network:
        ethernets:
            enp0s25:
                addresses: []
                dhcp4: true
                optional: true
        bridges:
            maasbr0:
                addresses: [ 10.3.99.25/24 ]
                dhcp4: no
                dhcp6: no
                interfaces: [ vlan15 ]
            staging:
                addresses: [ 10.3.98.25/24 ]
                dhcp4: no
                dhcp6: no
                interfaces: [ vlan10 ]
        vlans:
            vlan15:
                dhcp4: no
                dhcp6: no
                accept-ra: no
                id: 15
                link: enp0s25
            vlan10:
                dhcp4: no
                dhcp6: no
                accept-ra: no
                id: 10
                link: enp0s25
        version: 2Both VLANs are behind bridges as to allow setting virtual machines on any network. Additional configuration files were added to define these bridges for libvirt (/etc/libvirt/qemu/networks/maasbr0.xml):<network>
    <name>maasbr0</name>
    <bridge name="maasbr0">
    <forward mode="bridge">
    </forward></bridge></network>
    Libvirt also needs to be accessible from the network, so that MAAS can drive it using the "pod" feature. Uncomment "listen_tcp = 1", and set authentication as you see fit, in /etc/libvirt/libvirtd.conf. Also set:
    libvirtd_opts="-l"
    In /etc/default/libvirtd, then restart the libvirtd service.

    dnsmasq serverThe raspberrypi has similar netplan config, but sets up static addresses on all interfaces (since it is the DHCP server). Here, dnsmasq is used to provide DNS, DHCP, and TFTP. The configuration is in multiple files; but here are some of the important parts:dhcp-leasefile=/depot/dnsmasq/dnsmasq.leases
    dhcp-hostsdir=/depot/dnsmasq/reservations
    dhcp-authoritative
    dhcp-fqdn
    # copied from maas, specify boot files per-arch.
    dhcp-boot=tag:x86_64-efi,bootx64.efi
    dhcp-boot=tag:i386-pc,pxelinux
    dhcp-match=set:i386-pc, option:client-arch, 0 #x86-32
    dhcp-match=set:x86_64-efi, option:client-arch, 7 #EFI x86-64
    # pass search domains everywhere, it's easier to type short names
    dhcp-option=119,home.example.com,staging.example.com,maas.example.com
    domain=example.com
    no-hosts
    addn-hosts=/depot/dnsmasq/dns/
    domain-needed
    expand-hosts
    no-resolv
    # home network
    domain=home.example.com,10.3.0.0/23
    auth-zone=home.example.com,10.3.0.0/23
    dhcp-range=set:home,10.3.1.50,10.3.1.250,255.255.254.0,8h
    # specify the default gw / next router
    dhcp-option=tag:home,3,10.3.0.1
    # define the tftp server
    dhcp-option=tag:home,66,10.3.0.5
    # staging is configured as above, but on 10.3.98.0/24.
    # maas.example.com: "isolated" maas network.
    # send all DNS requests for X.maas.example.com to 10.3.99.25 (maas server)
    server=/maas.example.com/10.3.99.25
    # very basic tftp config
    enable-tftp
    tftp-root=/depot/tftp
    tftp-no-fail
    # set some "upstream" nameservers for general name resolution.
    server=8.8.8.8
    server=8.8.4.4

    DHCP reservations (to avoid IPs changing across reboots for some systems I know I'll want to reach regularly) are kept in /depot/dnsmasq/reservations (as per the above), and look like this:
    de:ad:be:ef:ca:fe,10.3.0.21
    I did put one per file, with meaningful filenames. This helps with debugging and making changes when network cards are changed, etc. The names used for the files do not match DNS names, but instead are a short description of the device (such as "thinkpad-x230"), since I may want to rename things later.
    Similarly, files in /depot/dnsmasq/dns have names describing the hardware, but then contain entries in hosts file form:
    10.3.0.21 izanagi
    Again, this is used so any rename of a device only requires changing the content of a single file in /depot/dnsmasq/dns, rather than also requiring renaming other files, or matching MAC addresses to make sure the right change is made.

    Installing MAASAt this point, the configuration for the networking should already be completed, and libvirt should be ready and accessible from the network.
    The MAAS installation process is very straightforward. Simply install the maas package, which will pull in maas-rack-controller and maas-region-controller.
    Once the configuration is complete, you can log in to the web interface. Use it to make sure, under Subnets, that only the MAAS-driven VLAN has DHCP enabled. To enable or disable DHCP, click the link in the VLAN column, and use the "Take action" menu to provide or disable DHCP.
    This is necessary if you do not want MAAS to fully manage all of the network and provide DNS and DHCP for all systems. In my case, I am leaving MAAS in its own isolated network since I would keep the server offline if I do not need it (and the home network needs to keep working if I'm away).
    Some extra modifications were made to the stock MAAS configuration to change the behavior of deployed systems. For example; I often test packages in -proposed, so it is convenient to have that enabled by default, with the archive pinned to avoid accidentally installing these packages. Given that I also do netplan development and might try things that would break the network connectivity, I also make sure there is a static password for the 'ubuntu' user, and that I have my own account created (again, with a static, known, and stupidly simple password) so I can connect to the deployed systems on their console. I have added the following to /etc/maas/preseed/curtin_userdata:

    late_commands:
    [...]
      pinning_00: ["curtin", "in-target", "--", "sh", "-c", "/bin/echo 'Package: *' >> /etc/apt/preferences.d/proposed"]
      pinning_01: ["curtin", "in-target", "--", "sh", "-c", "/bin/echo 'Pin: release a={{release}}-proposed' >> /etc/apt/preferences.d/proposed"]
      pinning_02: ["curtin", "in-target", "--", "sh", "-c", "/bin/echo 'Pin-Priority: -1' >> /etc/apt/preferences.d/proposed"]
    apt:
      sources:
        proposed.list:
          source: deb $MIRROR {{release}}-proposed main universe
    write_files:
      userconfig:
        path: /etc/cloud/cloud.cfg.d/99-users.cfg
        content: |
          system_info:
            default_user:
              lock_passwd: False
              plain_text_passwd: [REDACTED]
          users:
            - default
            - name: mtrudel
              groups: sudo
              gecos: Matt
              shell: /bin/bash
              lock-passwd: False
              passwd: [REDACTED]

    The pinning_ entries are simply added to the end of the "late_commands" section.
    For the libvirt instance, you will need to add it to MAAS using the maas CLI tool. For this, you will need to get your MAAS API key from the web UI (click your username, then look under MAAS keys), and run the following commands:
    maas login local   http://localhost:5240/MAAS/  [your MAAS API key]
    maas local pods create type=virsh power_address="qemu+tcp://127.0.1.1/system"
    The pod will be given a name automatically; you'll then be able to use the web interface to "compose" new machines and control them via MAAS. If you want to remotely use the systems' Spice graphical console, you may need to change settings for the VM to allow Spice connections on all interfaces, and power it off and on again.

    Setting up the clientDeployed hosts are now reachable normally over SSH by using their fully-qualified name, and specifying to use the ubuntu user (or another user you already configured):
    ssh ubuntu@vocal-toad.maas.example.com
    There is an inconvenience with using MAAS to control virtual machines like this, they are easy to reinstall, so their host hashes will change frequently if you access them via SSH. There's a way around that, using a specially crafted ssh_config (~/.ssh/config). Here, I'm sharing the relevant parts of the configuration file I use:
    CanonicalDomains home.example.com
    CanonicalizeHostname yes
    CanonicalizeFallbackLocal no
    HashKnownHosts no
    UseRoaming no
    # canonicalize* options seem to break github for some reason
    # I haven't spent much time looking into it, so let's make sure it will go through the
    # DNS resolution logic in SSH correctly.
    Host github.com
      Hostname github.com.
    Host *.maas
      Hostname %h.example.com
    Host *.staging
      Hostname %h.example.com
    Host *.maas.example.com
      User ubuntu
      StrictHostKeyChecking no
      UserKnownHostsFile /dev/null

    Host *.staging.example.com
      StrictHostKeyChecking no
      UserKnownHostsFile /dev/null
    Host *.lxd
      StrictHostKeyChecking no
      UserKnownHostsFile /dev/null
      ProxyCommand nc $(lxc list -c s4 $(basename %h .lxd) | grep RUNNING | cut -d' ' -f4) %p
    Host *.libvirt
      StrictHostKeyChecking no
      UserKnownHostsFile /dev/null
      ProxyCommand nc $(virsh domifaddr $(basename %h .libvirt) | grep ipv4 | sed 's/.* //; s,/.*,,') %p
    As a bonus, I have included some code that makes it easy to SSH to local libvirt systems or lxd containers.
    The net effect is that I can avoid having the warnings about changed hashes for MAAS-controlled systems and machines in the staging network, but keep getting them for all other systems.
    Now, this means that to reach a host on the MAAS network, a client system only needs to use the short name with .maas tacked on:
    vocal-toad.maasAnd the system will be reachable, and you will not have any warning about known host hashes (but do note that this is specific to a sandbox environment, you definitely want to see such warnings in a production environment, as it can indicate that the system you are connecting to might not be the one you think).
    It's not bad, but the goal would be to use just the short names. I am working around this using a tiny script:
    #!/bin/sh
    ssh $@.maas
    And I saved this as "sandbox" in ~/bin and making it executable.
    And with this, the lab is ready.
    UsageTo connect to a deployed system, one can now do the following:

    $ sandbox vocal-toad
    Warning: Permanently added 'vocal-toad.maas.example.com,10.3.99.12' (ECDSA) to the list of known hosts.
    Welcome to Ubuntu Cosmic Cuttlefish (development branch) (GNU/Linux 4.15.0-21-generic x86_64)
    [...]
    ubuntu@vocal-toad:~$
    ubuntu@vocal-toad:~$ id mtrudel
    uid=1000(mtrudel) gid=1000(mtrudel) groups=1000(mtrudel),27(sudo)
    MobilityOne important point for me was the mobility of the lab. While some of the network infrastructure must remain in place, I am able to undock the Thinkpad X230 (the MAAS server), and connect it via wireless to an external network. It will continue to "manage" or otherwise control VLAN 15 on the wired interface. In these cases, I bring another small configurable switch: a Cisco Catalyst 2960 (8 ports + 1), which is set up with the VLANs. A client could then be connected directly on VLAN 15 behind the MAAS server, and is free to make use of the MAAS proxy service to reach the internet. This allows me to bring the MAAS server along with all its virtual machines, as well as to be able to deploy new systems by connecting them to the switch. Both systems fit easily in a standard laptop bag along with another laptop (a "client").
    All the systems used in the "semi-permanent" form of this lab can easily run on a single home power outlet, so issues are unlikely to arise in mobile form. The smaller switch is rated for 0.5amp, and two laptops do not pull very much power.
    Next stepsOne of the issues that remains with this setup is that it is limited to either starting MAAS images or starting images that are custom built and hooked up to the raspberry pi, which leads to a high effort to integrate new images:
    • Custom (desktop?) images could be loaded into MAAS, to facilitate starting a desktop build.
    • Automate customizing installed packages based on tags applied to the machines.
      • juju would shine there; it can deploy workloads based on available machines in MAAS with the specified tags.
      • Also install a generic system with customized packages, not necessarily single workloads, and/or install extra packages after the initial system deployment.
        • This could be done using chef or puppet, but will require setting up the infrastructure for it.
      • Integrate automatic installation of snaps.
    • Load new images into the raspberry pi automatically for netboot / preseeded installs
      • I have scripts for this, but they will take time to adapt
      • Space on such a device is at a premium, there must be some culling of old images
    Categories: Linux

    Jonathan Carter: Video Channel Updates

    Planet Ubuntu - Wed, 05/16/2018 - 12:19

    Last month, I started doing something that I’ve been meaning to do for years, and that’s to start a video channel and make some free software related videos.

    I started out uploading to my YouTube channel which has been dormant for a really long time, and then last week, I also uploaded my videos to my own site, highvoltage.tv. It’s a MediaDrop instance, a video hosting platform written in Python.

    I’ll still keep uploading to YouTube, but ultimately I’d like to make my self-hosted site the primary source for my content. Not sure if I’ll stay with MediaDrop, but it does tick a lot of boxes, and if its easy enough to extend, I’ll probably stick with it. MediaDrop might also be a good platform for viewing the Debian meetings videos like the DebConf videos. 

    My current topics are very much Debian related, but that doesn’t exclude any other types of content from being included in the future. Here’s what I have so far:

    • Video Logs: Almost like a blog, in video format.
    • Howto: Howto videos.
    • Debian Package of the Day: Exploring packages in the Debian archive.
    • Debian Package Management: Howto series on Debian package management, a precursor to a series that I’ll do on Debian packaging.
    • What’s the Difference: Just comparing 2 or more things.
    • Let’s Internet: Read stuff from Reddit, Slashdot, Quora, blogs and other media.

    It’s still early days and there’s a bunch of ideas that I still want to implement, so the content will hopefully get a lot better as time goes on.

    I have also quit Facebook last month, so I dusted off my old Mastodon account and started posting there again: https://mastodon.xyz/@highvoltage

    You can also subscribe to my videos via RSS: https://highvoltage.tv/latest.xml

    Other than that I’m open to ideas, thanks for reading :)

    Categories: Linux

    Sina Mashek: I miss contributing code

    Planet Ubuntu - Tue, 05/15/2018 - 15:00

    Something I need to force myself to do again is make tools that are potentially useful for others. Or better yet, find tools that someone else made that do the same/similar thing, and contribute to them!

    At some point between my being steeped in the Ubuntu Beginners Team1 and now, I stopped contributing heavily to existing projects, and got sucked into the thrill of building shit for just myself.

    The funniest part is having looked around lately, I have ditched almost everything I’ve built myself because I found that someone/another team of people have built what I wanted -but better.

    Learning how to build those things was great and all, but I could have probably learned a little faster (and other non-programming skills) by contributing to an existing project.

    Basically, I think it’s time for me to start contributing to the tools I use again.

    1. whah, the UBT hasn’t been around for such a long time now!
    Categories: Linux

    Raphaël Hertzog: Freexian’s report about Debian Long Term Support, April 2018

    Planet Ubuntu - Tue, 05/15/2018 - 09:32

    Like each month, here comes a report about the work of paid contributors to Debian LTS.

    Individual reports

    In March, about 183 work hours have been dispatched among 13 paid contributors. Their reports are available:

    • Abhijith PA did 5 hours (out of 10 hours allocated, thus keeping 5 extra hours for May).
    • Antoine Beaupré did 12h.
    • Ben Hutchings did 17 hours (out of 15h allocated + 2 remaining hours).
    • Brian May did 10 hours.
    • Chris Lamb did 16.25 hours.
    • Emilio Pozuelo Monfort did 11.5 hours (out of 16.25 hours allocated + 5 remaining hours, thus keeping 9.75 extra hours for May).
    • Holger Levsen did nothing (out of 16.25 hours allocated + 16.5 hours remaining, thus keeping 32.75 extra hours for May). He did not get hours allocated for May and is expected to catch up.
    • Hugo Lefeuvre did 20.5 hours (out of 16.25 hours allocated + 4.25 remaining hours).
    • Markus Koschany did 16.25 hours.
    • Ola Lundqvist did 11 hours (out of 14 hours allocated + 9.5 remaining hours, thus keeping 12.5 extra hours for May).
    • Roberto C. Sanchez did 7 hours (out of 16.25 hours allocated + 15.75 hours remaining, but immediately gave back the 25 remaining hours).
    • Santiago Ruano Rincón did 8 hours.
    • Thorsten Alteholz did 16.25 hours.
    Evolution of the situation

    The number of sponsored hours did not change. But a few sponsors interested in having more than 5 years of support should join LTS next month since this was a pre-requisite to benefit from extended LTS support. I did update Freexian’s website to show this as a benefit offered to LTS sponsors.

    The security tracker currently lists 20 packages with a known CVE and the dla-needed.txt file 16. At two week from Wheezy’s end-of-life, the number of open issues is close to an historical low.

    Thanks to our sponsors

    New sponsors are in bold.

    No comment | Liked this article? Click here. | My blog is Flattr-enabled.

    Categories: Linux

    Jono Bacon: Video: How to Manage Failure and Poor Decisions – A Practical Guide

    Planet Ubuntu - Mon, 05/14/2018 - 15:12

    I realized I haven’t been putting many videos online recently. As such, I have started recording some instructional and coaching videos that I am putting online that I hope are useful to you folks.

    To get started, I wanted to touch on the topic of handling failure and poor decisions in a way that helps to identify pragmatic outcomes and lead towards better outcomes. This video introduces the issue, delves into how to unpick and understand the components of failure, and some practical recommendations for concrete next steps after this assessment.

    Here is the video:

    Can’t see it? Click here.

    The post Video: How to Manage Failure and Poor Decisions – A Practical Guide appeared first on Jono Bacon.

    Categories: Linux

    Daniel Pocock: A closer look at power and PowerPole

    Planet Ubuntu - Mon, 05/14/2018 - 13:25

    The crowdfunding campaign has so far raised enough money to buy a small lead-acid battery but hopefully with another four days to go before OSCAL we can reach the target of an AGM battery. In the interest of transparency, I will shortly publish a summary of the donations.

    The campaign has been a great opportunity to publish some information that will hopefully help other people too. In particular, a lot of what I've written about power sources isn't just applicable for ham radio, it can be used for any demo or exhibit involving electronics or electrical parts like motors.

    People have also asked various questions and so I've prepared some more details about PowerPoles today to help answer them.

    OSCAL organizer urgently looking for an Apple MacBook PSU

    In an unfortunate twist of fate while I've been blogging about power sources, one of the OSCAL organizers has a MacBook and the Apple-patented PSU conveniently failed just a few days before OSCAL. It is the 85W MagSafe 2 PSU and it is not easily found in Albania. If anybody can get one to me while I'm in Berlin at Kamailio World then I can take it to Tirana on Wednesday night. If you live near one of the other OSCAL speakers you could also send it with them.

    If only Apple used PowerPole...

    Why batteries?

    The first question many people asked is why use batteries and not a power supply. There are two answers for this: portability and availability. Many hams like to operate their radios away from their home sometimes. At an event, you don't always know in advance whether you will be close to a mains power socket. Taking a battery eliminates that worry. Batteries also provide better availability in times of crisis: whenever there is a natural disaster, ham radio is often the first mode of communication to be re-established. Radio hams can operate their stations independently of the power grid.

    Note that while the battery looks a lot like a car battery, it is actually a deep cycle battery, sometimes referred to as a leisure battery. This type of battery is often promoted for use in caravans and boats.

    Why PowerPole?

    Many amateur radio groups have already standardized on the use of PowerPole in recent years. The reason for having a standard is that people can share power sources or swap equipment around easily, especially in emergencies. The same logic applies when setting up a demo at an event where multiple volunteers might mix and match equipment at a booth.

    WICEN, ARES / RACES and RAYNET-UK are some of the well known groups in the world of emergency communications and they all recommend PowerPole.

    Sites like eBay and Amazon have many bulk packs of PowerPoles. Some are genuine, some are copies. In the UK, I've previously purchased PowerPole packs and accessories from sites like Torberry and Sotabeams.

    The pen is mightier than the sword, but what about the crimper?

    The PowerPole plugs for 15A, 30A and 45A are all interchangeable and they can all be crimped with a single tool. The official tool is quite expensive but there are many after-market alternatives like this one. It takes less than a minute to insert the terminal, insert the wire, crimp and make a secure connection.

    Here are some packets of PowerPoles in every size:

    Example cables

    It is easy to make your own cables or to take any existing cables, cut the plugs off one end and put PowerPoles on them.

    Here is a cable with banana plugs on one end and PowerPole on the other end. You can buy cables like this or if you already have cables with banana plugs on both ends, you can cut them in half and put PowerPoles on them. This can be a useful patch cable for connecting a desktop power supply to a PowerPole PDU:

    Here is the Yaesu E-DC-20 cable used to power many mobile radios. It is designed for about 25A. The exposed copper section simply needs to be trimmed and then inserted into a PowerPole 30:

    Many small devices have these round 2.1mm coaxial power sockets. It is easy to find a packet of the pigtails on eBay and attach PowerPoles to them (tip: buy the pack that includes both male and female connections for more versatility). It is essential to check that the devices are all rated for the same voltage: if your battery is 12V and you connect a 5V device, the device will probably be destroyed.

    Distributing power between multiple devices

    There are a wide range of power distribution units (PDUs) for PowerPole users. Notice that PowerPoles are interchangeable and in some of these devices you can insert power through any of the inputs. Most of these devices have a fuse on every connection for extra security and isolation. Some of the more interesting devices also have a USB charging outlet. The West Mountain Radio RigRunner range includes many permutations. You can find a variety of PDUs from different vendors through an Amazon search or eBay.

    In the photo from last week's blog, I have the Fuser-6 distributed by Sotabeams in the UK (below, right). I bought it pre-assembled but you can also make it yourself. I also have a Windcamp 8-port PDU purchased from Amazon (left):

    Despite all those fuses on the PDU, it is also highly recommended to insert a fuse in the section of wire coming off the battery terminals or PSU. It is easy to find maxi blade fuse holders on eBay and in some electrical retailers:

    Need help crimping your cables?

    If you don't want to buy a crimper or you would like somebody to help you, you can bring some of your cables to a hackerspace or ask if anybody from the Debian hams team will bring one to an event to help you.

    I'm bringing my own crimper and some PowerPoles to OSCAL this weekend, if you would like to help us power up the demo there please consider contributing to the crowdfunding campaign.

    Categories: Linux

    The Fridge: Ubuntu Weekly Newsletter Issue 527

    Planet Ubuntu - Mon, 05/14/2018 - 13:10

    Welcome to the Ubuntu Weekly Newsletter, Issue 527 for the week of May 6 – 12, 2018. The full version of this issue is available here.

    In this issue we cover:

    The Ubuntu Weekly Newsletter is brought to you by:

    • Krytarik Raido
    • Bashing-om
    • Chris Guiver
    • Wild Man
    • And many others

    If you have a story idea for the Weekly Newsletter, join the Ubuntu News Team mailing list and submit it. Ideas can also be added to the wiki!

    Except where otherwise noted, this issue of the Ubuntu Weekly Newsletter is licensed under a Creative Commons Attribution ShareAlike 3.0 License

    Categories: Linux

    Ubuntu Studio: Ubuntu Studio Development News – May 14, 2018

    Planet Ubuntu - Mon, 05/14/2018 - 12:44
    Plans for Ubuntu Studio 18.10 – Cosmic Cuttlefish For Ubuntu 18.10, we have been starting to think outside-the-box. There is something to be said of remaining with what you you have and refining it, but staying in one spot can lead quickly to stagnation. Coming up with new ideas and progressing forward with those ideas […]
    Categories: Linux

    Lubuntu Blog: This Week in Lubuntu Development #5

    Planet Ubuntu - Sun, 05/13/2018 - 20:56
    Here is the fifth issue of This Week in Lubuntu Development. You can read the previous issue here. Changes General Lubuntu 18.04 was released! Some work was done on the Lubuntu Manual by Lubuntu contributor Lyn Perrine and Lubuntu Translations Team Lead Marcin Mikołajczak. You can see the commits they have made here. We need […]
    Categories: Linux

    Andrea Corbellini: 11 years of Ubuntu membership

    Planet Ubuntu - Sat, 05/12/2018 - 15:30

    It's been 11 years and 1 month since I was awarded with official Ubuntu membership. I will never forget that day: as a kid I had to write about myself on IRC, in front of the Community Council members and answer their questions in a language that was not my primary one. I must confess that I was a bit scared that evening, but once I made it, it felt so good. It felt good not just because of the award itself, but rather because that was the recognition that I did something that mattered. I did something useful that other people could benefit from. And for me, that meant a lot.

    So much time has passed since then. So many things have changed both in my life and around me, for better or worse. So many that I cannot even enumerate all of them. Nonetheless, deep inside of me, I still feel like that young kid: curious, always ready to experiment, full of hopes and uncertain (but never scared) about the future.

    Through the years I received the support of a bunch of people who believed in me, and I thank them all. But if today I feel so hopeful it's undoubtedly thanks to one person in particular, a person who holds a special place in my life. A big thank you goes to you.

    Categories: Linux

    Ubuntu Podcast from the UK LoCo: S11E10 – Ten Little Ladybugs - Ubuntu Podcast

    Planet Ubuntu - Fri, 05/11/2018 - 08:00

    This week we’ve been smashing up a bathroom like rock stars. We discuss the Ubuntu 18.04 (Bionic Beaver) LTS release, serve up some command line love and go over your feedback.

    It’s Season 11 Episode 10 of the Ubuntu Podcast! Alan Pope, Mark Johnson and Martin Wimpress are connected and speaking to your brain.

    In this week’s show:

    • We discuss what we’ve been up to recently:
      • Mark has been smashing his bathroom.
    • We discuss the Ubuntu 18.04 (Bionic Beaver) LTS release.

    • We share a Command Line Lurve:

      • yes – repeatedly output “y” or specified string for piping into interactive programs
    yes | fsck /var
    • And we go over all your amazing feedback – thanks for sending it – please keep sending it!

    • Image credit: Kirstyn Paynter

    That’s all for this week! You can listen to the Ubuntu Podcast back catalogue on YouTube. If there’s a topic you’d like us to discuss, or you have any feedback on previous shows, please send your comments and suggestions to show@ubuntupodcast.org or Tweet us or Comment on our Facebook page or comment on our Google+ page or comment on our sub-Reddit.

    Categories: Linux

    Simos Xenitellis: A closer look at Chrome OS using LXD to run Linux GUI apps (Project Crostini)

    Planet Ubuntu - Fri, 05/11/2018 - 07:14

    At Google I/O 2018, one of the presentations was on What’s new in Android apps for Chrome OS (Google I/O ’18). The third and most exciting developer tool shown in the presentation, was the ability to run graphical Linux apps on Chrome OS. Here is a screenshot of a native Linux terminal application, as shown in the presentation.

    They were so excited that the presenter said it would knock the socks off of the participants. And they had arranged a giveaway of socks. Actual socks swag to those attending the presentation 8-).

    The way that they get the GUI apps from the LXD container to appear to the screen, is similar to

    How to run graphics-accelerated GUI apps in LXD containers on your Ubuntu desktop

    Project Crostini

    Project Crostini is the Chrome OS project to add support to run Linux GUI apps on Chrome OS.

    The components that facilitate Project Crostini can be found at https://github.com/lstoll/cros-crostini That page has instructions for those that wanted to enable the running of Linux GUI apps on Chrome OS, when Project Crostini was still under development. Lincoln Stoll dissected the source of Chrome OS and created a helpful list of the involved repositories.

    The basic component is The Chrome OS Virtual Machine Monitor (crossvm), which runs untrusted operating systems through Linux’s KVM interface. The Linux distribution would run in a VM. The test repositories make reference to the X server, XWayland and Wayland. There is a repository called sommelier, which is a nested Wayland compositor with X11 forwarding support. It needs more searching to figure out where the source code ended into the Chrome OS repository and what is actually being used.

    Update #1: Here are the vm_tools in Chrome OS. They include garcon,  a service that gets added in the container and communicates with another service outside of the container (vm_concierge).

    What is important, is that LXD runs in this VM and is configured to launch a machine container with a Linux distribution. We are going in depth into this.

    LXD in Project Crostini

    Here is the file that does the initial configuration of the LXD service. It preseeds LXD with the following configuration.

    1. It uses a storage pool with the btrfs filesystem.
    2. It sets up a private bridge for networking.
    3. It configures the default LXD profile with relevant settings that will be applied to the container when it gets created.
      1. The container will not autostart when the Chromebook is restarted. It will get started manually.
      2. There will be private networking.
      3. The directory /opt/google/cros-containers of the host gets shared into the container as both /opt/google/cros-containers and /opt/google/garcon.
      4. The container will be able to get the IP address of the host from the file /dev/.host_ip (inside the container).
      5. The Wayland socket of the VM is shared to the container. This means that GUI applications that run in the container, can appear in the X server running in the VM of Chrome OS.
      6. The /dev/wl0 device file of the host is shared into the container as /dev/wl0. With permissions 0666. That’s the wireless interface.
    # Storage pools storage_pools: - name: default driver: btrfs config: source: /mnt/stateful/lxd/storage-pools/default # Network # IPv4 address is configured by the host. networks: - name: lxdbr0 type: bridge config: ipv4.address: none ipv6.address: none # Profiles profiles: - name: default config: boot.autostart: false devices: root: path: / pool: default type: disk eth0: nictype: bridged parent: lxdbr0 type: nic cros_containers: path: /opt/google/cros-containers source: /opt/google/cros-containers type: disk garcon: path: /opt/google/garcon source: /opt/google/cros-containers type: disk host-ip: path: /dev/.host_ip source: /run/host_ip type: disk wayland-sock: path: /dev/.wayland-0 source: /run/wayland-0 type: disk wl0: source: /dev/wl0 type: unix-char mode: 0666

    Here it creates the btrfs storage pool (termina-lxd-scripts/files/stateful_setup.sh),

    mkfs.btrfs /dev/vdb || true # The disk may already be formatted. mount -o user_subvol_rm_allowed /dev/vdb /mnt/stateful

    With the completed LXD configuration, let’s see how the container gets created. It is this file, termina-lxd-scripts/files/run_container.sh Specifically,

    1. It configures an LXD remote URL, https://storage.googleapis.com/cros-containers, that has the container image. It is accessible through the simplestreams protocol.
    2. It launches the container image with
      lxc launch google:debian/stretch
    How to try google:debian/stretch on our own LXD installation

    Let’s delve deeper in the container image that is used in Chrome OS. For this, we are adding the LXD remote URL and then launch the container.

    First, let’s add the LXD remote.

    $ lxc remote add google https://storage.googleapis.com/cros-containers --protocol=simplestreams

    Let’s verify that it has been added.

    $ lxc remote list +--------+------------------------------------------------+---------------+-----------+--------+--------+ | NAME | URL | PROTOCOL | AUTH TYPE | PUBLIC | STATIC | +---------------------------------------------------------+---------------+-----------+--------+--------+ | google | https://storage.googleapis.com/cros-containers | simplestreams | | YES | NO | +---------------------------------------------------------+---------------+-----------+--------+--------+ | images | https://images.linuxcontainers.org | simplestreams | | YES | NO | +---------------------------------------------------------+---------------+-----------+--------+--------+ | local (default) | unix:// | lxd | tls | NO | YES | +---------------------------------------------------------+---------------+-----------+--------+--------+ | ubuntu | https://cloud-images.ubuntu.com/releases | simplestreams | | YES | YES | +---------------------------------------------------------+---------------+-----------+--------+--------+ | ubuntu-daily | https://cloud-images.ubuntu.com/daily | simplestreams | | YES | YES | +---------------------------------------------------------+---------------+-----------+--------+--------+

    What’s in the google: container image repository?

    $ lxc image list google: +-------------------------+--------------+--------+-------------------------------------------------------+--------+----------+------------------------------+ | ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION | ARCH | SIZE | UPLOAD DATE | +-------------------------+--------------+--------+-------------------------------------------------------+--------+----------+------------------------------+ | debian/stretch (3 more) | 706f2390a7f6 | yes | Debian for Chromium OS stretch amd64 (20180504_22:19) | x86_64 | 194.82MB | May 4, 2018 at 12:00am (UTC) | +-------------------------+--------------+--------+-------------------------------------------------------+--------+----------+------------------------------+

    It is a single image for x86_64, based on Debian Stretch (20180504_22:19).

    Let’s see again those details for the specific container image from Google.

    $ lxc image show google:debian/stretch auto_update: false properties: architecture: amd64 description: Debian for Chromium OS stretch amd64 (20180504_22:19) os: Debian for Chromium OS release: stretch serial: "20180504_22:19" public: true

    Compare those details with the stock debian/stretch container image,

    $ lxc image show images:debian/stretch auto_update: false properties: architecture: amd64 description: Debian stretch amd64 (20180511_05:25) os: Debian release: stretch serial: "20180511_05:25" public: true

    Can we then get detailed info of the Google container image?

    $ lxc image info google:debian/stretch Fingerprint: 706f2390a7f67655df8d0d5d46038ed993ad28cb161648781fbd60af4b52dd76 Size: 194.82MB Architecture: x86_64 Public: yes Timestamps: Created: 2018/05/04 00:00 UTC Uploaded: 2018/05/04 00:00 UTC Expires: never Last used: never Properties: serial: 20180504_22:19 description: Debian for Chromium OS stretch amd64 (20180504_22:19) os: Debian for Chromium OS release: stretch architecture: amd64 Aliases: - debian/stretch/default - debian/stretch/default/amd64 - debian/stretch - debian/stretch/amd64 Cached: no Auto update: disabled

    Compare those details with the stock debian/stretch container image.

    $ lxc image info images:debian/stretch Fingerprint: 07341ea710a44508c12e5b3b437bd13fa334e56b3c4e2808c32fd7e6b12df8d1 Size: 110.22MB Architecture: x86_64 Public: yes Timestamps: Created: 2018/05/11 00:00 UTC Uploaded: 2018/05/11 00:00 UTC Expires: never Last used: never Properties: os: Debian release: stretch architecture: amd64 serial: 20180511_05:25 description: Debian stretch amd64 (20180511_05:25) Aliases: - debian/stretch/default - debian/stretch/default/amd64 - debian/9/default - debian/9/default/amd64 - debian/stretch - debian/stretch/amd64 - debian/9 - debian/9/amd64 Cached: no Auto update: disabled

    Up to now we learned that the Google debian/stretch container image has 95MB of extra files (compressed).

    It’s time to launch a container with google:debian/stretch!

    $ lxc launch google:debian/stretch chrome-os-linux Creating chrome-os-linux Starting chrome-os-linux $

    Now, get a shell into this container.

    $ lxc exec chrome-os-linux bash root@chrome-os-linux:~#

    There is no non-root account,

    root@chrome-os-linux:~# ls /home/ root@chrome-os-linux:~# Differences with stock debian/stretch image

    These are the Chrome OS-specific packages that the container image has. These are not architecture-specific files (architecture: all).

    ii cros-adapta 0.1 all Chromium OS GTK Theme This package provides symlinks ii cros-apt-config 0.12 all APT config for Chromium OS integration. This package ii cros-garcon 0.10 all Chromium OS Garcon Bridge. This package provides the ii cros-guest-tools 0.12 all Metapackage for Chromium OS integration. This package has ii cros-sommelier 0.11 all sommelier base package. This package installs unitfiles ii cros-sommelier-config 0.11 all sommelier config for Chromium OS integration. This ii cros-sudo-config 0.10 all sudo config for Chromium OS integration. This package ii cros-systemd-overrides 0.10 all systemd overrides for running under Chromium OS. This ii cros-ui-config 0.11 all UI integration for Chromium OS This package installs ii cros-unattended-upgrades 0.10 all Unattended upgrades config. This package installs an ii cros-wayland 0.10 all Wayland extras for virtwl in Chromium OS. This package

    There are 305 additional packages in total in the Chrome OS container image of Debian stretch, compared to the stock Debian Stretch image.

    adwaita-icon-theme apt-transport-https apt-utils at-spi2-core bash-completion ca-certificates cpp cpp-6 cros-adapta cros-apt-config cros-garcon cros-guest-tools cros-sommelier cros-sommelier-config cros-sudo-config cros-systemd-overrides cros-ui-config cros-unattended-upgrades cros-wayland curl dbus-x11 dconf-cli dconf-gsettings-backend:amd64 dconf-service desktop-file-utils dh-python distro-info-data fontconfig fontconfig-config fonts-croscore fonts-dejavu-core fonts-roboto fonts-roboto-hinted glib-networking:amd64 glib-networking-common glib-networking-services gnome-icon-theme gsettings-desktop-schemas gtk-update-icon-cache hicolor-icon-theme i965-va-driver:amd64 less libapt-inst2.0:amd64 libasound2:amd64 libasound2-data libasound2-plugins:amd64 libasyncns0:amd64 libatk-bridge2.0-0:amd64 libatk1.0-0:amd64 libatk1.0-data libatspi2.0-0:amd64 libauthen-sasl-perl libavahi-client3:amd64 libavahi-common-data:amd64 libavahi-common3:amd64 libavcodec57:amd64 libavresample3:amd64 libavutil55:amd64 libcairo-gobject2:amd64 libcairo2:amd64 libcolord2:amd64 libcroco3:amd64 libcrystalhd3:amd64 libcups2:amd64 libcurl3:amd64 libcurl3-gnutls:amd64 libdatrie1:amd64 libdconf1:amd64 libdrm-amdgpu1:amd64 libdrm-intel1:amd64 libdrm-nouveau2:amd64 libdrm-radeon1:amd64 libdrm2:amd64 libegl1-mesa:amd64 libencode-locale-perl libepoxy0:amd64 libffi6:amd64 libfile-basedir-perl libfile-desktopentry-perl libfile-listing-perl libfile-mimeinfo-perl libflac8:amd64 libfont-afm-perl libfontconfig1:amd64 libfontenc1:amd64 libfreetype6:amd64 libgail-common:amd64 libgail18:amd64 libgbm1:amd64 libgdbm3:amd64 libgdk-pixbuf2.0-0:amd64 libgdk-pixbuf2.0-common libgl1-mesa-dri:amd64 libgl1-mesa-glx:amd64 libglapi-mesa:amd64 libglib2.0-0:amd64 libglib2.0-data libgmp10:amd64 libgnutls30:amd64 libgomp1:amd64 libgraphite2-3:amd64 libgsm1:amd64 libgtk-3-0:amd64 libgtk-3-bin libgtk-3-common libgtk2.0-0:amd64 libgtk2.0-bin libgtk2.0-common libharfbuzz0b:amd64 libhogweed4:amd64 libhtml-form-perl libhtml-format-perl libhtml-parser-perl libhtml-tagset-perl libhtml-tree-perl libhttp-cookies-perl libhttp-daemon-perl libhttp-date-perl libhttp-message-perl libhttp-negotiate-perl libice6:amd64 libicu57:amd64 libidn2-0:amd64 libio-html-perl libio-socket-ssl-perl libipc-system-simple-perl libisl15:amd64 libjack-jackd2-0:amd64 libjbig0:amd64 libjpeg62-turbo:amd64 libjson-glib-1.0-0:amd64 libjson-glib-1.0-common liblcms2-2:amd64 libldap-2.4-2:amd64 libldap-common libllvm3.9:amd64 libltdl7:amd64 liblwp-mediatypes-perl liblwp-protocol-https-perl libmailtools-perl libmp3lame0:amd64 libmpc3:amd64 libmpdec2:amd64 libmpfr4:amd64 libnet-dbus-perl libnet-http-perl libnet-smtp-ssl-perl libnet-ssleay-perl libnettle6:amd64 libnghttp2-14:amd64 libnuma1:amd64 libogg0:amd64 libopenjp2-7:amd64 libopus0:amd64 liborc-0.4-0:amd64 libp11-kit0:amd64 libpango-1.0-0:amd64 libpangocairo-1.0-0:amd64 libpangoft2-1.0-0:amd64 libpciaccess0:amd64 libperl5.24:amd64 libpixman-1-0:amd64 libpng16-16:amd64 libpolkit-agent-1-0:amd64 libpolkit-backend-1-0:amd64 libpolkit-gobject-1-0:amd64 libproxy1v5:amd64 libpsl5:amd64 libpulse0:amd64 libpulsedsp:amd64 libpython3-stdlib:amd64 libpython3.5-minimal:amd64 libpython3.5-stdlib:amd64 libreadline7:amd64 librest-0.7-0:amd64 librsvg2-2:amd64 librsvg2-common:amd64 librtmp1:amd64 libsamplerate0:amd64 libsasl2-2:amd64 libsasl2-modules:amd64 libsasl2-modules-db:amd64 libsensors4:amd64 libshine3:amd64 libsm6:amd64 libsnappy1v5:amd64 libsndfile1:amd64 libsoup-gnome2.4-1:amd64 libsoup2.4-1:amd64 libsoxr0:amd64 libspeex1:amd64 libspeexdsp1:amd64 libsqlite3-0:amd64 libssh2-1:amd64 libssl1.1:amd64 libswresample2:amd64 libtasn1-6:amd64 libtdb1:amd64 libtext-iconv-perl libthai-data libthai0:amd64 libtheora0:amd64 libtie-ixhash-perl libtiff5:amd64 libtimedate-perl libtwolame0:amd64 libtxc-dxtn-s2tc:amd64 libunistring0:amd64 liburi-perl libva-drm1:amd64 libva-x11-1:amd64 libva1:amd64 libvdpau-va-gl1:amd64 libvdpau1:amd64 libvorbis0a:amd64 libvorbisenc2:amd64 libvpx4:amd64 libwavpack1:amd64 libwayland-client0:amd64 libwayland-cursor0:amd64 libwayland-egl1-mesa:amd64 libwayland-server0:amd64 libwebp6:amd64 libwebpmux2:amd64 libwebrtc-audio-processing1:amd64 libwrap0:amd64 libwww-perl libwww-robotrules-perl libx11-protocol-perl libx11-xcb1:amd64 libx264-148:amd64 libx265-95:amd64 libxaw7:amd64 libxcb-dri2-0:amd64 libxcb-dri3-0:amd64 libxcb-glx0:amd64 libxcb-present0:amd64 libxcb-render0:amd64 libxcb-shape0:amd64 libxcb-shm0:amd64 libxcb-sync1:amd64 libxcb-xfixes0:amd64 libxcomposite1:amd64 libxcursor1:amd64 libxdamage1:amd64 libxfixes3:amd64 libxft2:amd64 libxi6:amd64 libxinerama1:amd64 libxkbcommon0:amd64 libxml-parser-perl libxml-twig-perl libxml-xpathengine-perl libxml2:amd64 libxmu6:amd64 libxpm4:amd64 libxrandr2:amd64 libxrender1:amd64 libxshmfence1:amd64 libxt6:amd64 libxtst6:amd64 libxv1:amd64 libxvidcore4:amd64 libxxf86dga1:amd64 libxxf86vm1:amd64 libzvbi-common libzvbi0:amd64 lsb-release mesa-va-drivers:amd64 mesa-vdpau-drivers:amd64 mime-support openssl perl perl-modules-5.24 perl-openssl-defaults:amd64 policykit-1 publicsuffix pulseaudio pulseaudio-utils python-apt-common python3 python3-apt python3-minimal python3.5 python3.5-minimal readline-common rename rtkit sgml-base shared-mime-info sudo tcpd ucf unattended-upgrades unzip va-driver-all:amd64 vdpau-driver-all:amd64 x11-common x11-utils x11-xserver-utils xdg-user-dirs xdg-utils xkb-data xml-core xz-utils

    The binary files are meant to be found at /opt/google/cros-containers/. For example,

    root@chrome-os-linux:~# cat /usr/bin/gnome-www-browser #!/bin/bash /opt/google/cros-containers/bin/garcon --client --url "$@" root@chrome-os-linux:~#

    Obviously, these files are not found in the container that I just launched. These files are provided by Chrome OS of a the Chromebook.

    I did not find binaries in the container to launch a Linux terminal application. I assume would be found at /opt/google/cros-containers/bin/ as well.

    The Chrome OS deb package repository

    Here is the repository,

    root@chrome-os-linux:~# cat /etc/apt/sources.list.d/cros.list deb https://storage.googleapis.com/cros-packages stretch main root@chrome-os-linux:~#

    And here are the details of the packages,

    $ curl https://storage.googleapis.com/cros-packages/dists/stretch/main/binary-amd64/Packages Package: cros-adapta Version: 0.1 Architecture: all Recommends: libgtk2.0-0, libgtk-3-0 Maintainer: The Chromium OS Authors <chromium-os-dev@chromium.org> Priority: optional Section: misc Filename: pool/main/c/cros-adapta/cros-adapta_0.1_all.deb Size: 792 SHA256: 885783a862f75fb95e0d389c400b9463c9580a84e9ec54c1ed2c8dbafa1ccbc5 SHA1: 23cbf5f11724d971592da9db9a17b2ae1c28dfad MD5sum: 27fdba7a27c84caa4014a69546a83a6b Description: Chromium OS GTK Theme This package provides symlinks which link the bind-mounted theme into the correct location in the container. Homepage: https://chromium.googlesource.com/chromiumos/third_party/cros-adapta/ Built-Using: Bazel Package: cros-apt-config Version: 0.12 Architecture: all Depends: apt-transport-https Maintainer: The Chromium OS Authors <chromium-os-dev@chromium.org> Priority: optional Section: misc Filename: pool/main/c/cros-apt-config/cros-apt-config_0.12_all.deb Size: 7358 SHA256: d6d21bdf348e6510a9c933f8aacde7ac4054b6e2f56d5e13e9772800fab13e9e SHA1: 51b23541fc8029725966bf45f0a98075cbb01dfa MD5sum: b3de74124b2947e0ad819416ce7eed78 Description: APT config for Chromium OS integration. This package installs the keyring for the Chromium OS integration apt repo, the source list, and APT preferences. Homepage: https://chromium.org Built-Using: Bazel Package: cros-garcon Version: 0.10 Architecture: all Depends: desktop-file-utils, xdg-utils Maintainer: The Chromium OS Authors <chromium-os-dev@chromium.org> Priority: optional Section: misc Filename: pool/main/c/cros-garcon/cros-garcon_0.10_all.deb Size: 1330 SHA256: 32430b920770a8f6d5e0f271de340e87afb32bd9c2a4ecc4e470318e37033672 SHA1: 46f24826d9a0eaab8ec1617d173c48f15fedd937 MD5sum: 4ab2fa3b50ec42bddf6aeeb93c1ef202 Description: Chromium OS Garcon Bridge. This package provides the systemd unit files for Garcon, the bridge to Chromium OS. Homepage: https://chromium.org Built-Using: Bazel Package: cros-guest-tools Version: 0.12 Architecture: all Depends: cros-garcon, cros-sommelier Recommends: bash-completion, cros-apt-config, cros-sommelier-config, cros-sudo-config, cros-systemd-overrides, cros-ui-config, cros-unattended-upgrades, cros-wayland, curl, dbus-x11, pulseaudio, unzip, vim Maintainer: The Chromium OS Authors <chromium-os-dev@chromium.org> Priority: optional Section: misc Filename: pool/main/c/cros-guest-tools/cros-guest-tools_0.12_all.deb Size: 10882 SHA256: 5f0a2521351b22fe3b537431dec59740c6cc96771372432fe3c7a88a5939884d SHA1: d37aab929c0c7011dd6b730bdc2052d7e232d577 MD5sum: 5d9fafa14a4f88108f716438c45cf390 Description: Metapackage for Chromium OS integration. This package has dependencies on all other packages necessary for Chromium OS integration. Homepage: https://chromium.org Built-Using: Bazel Package: cros-sommelier Version: 0.11 Architecture: all Depends: libpam-systemd Recommends: x11-utils, x11-xserver-utils, xkb-data Maintainer: The Chromium OS Authors <chromium-os-dev@chromium.org> Priority: optional Section: misc Filename: pool/main/c/cros-sommelier/cros-sommelier_0.11_all.deb Size: 1552 SHA256: 522fe94157708d1a62c42a404bcffe537205fd7ea7b0d4a1ed98de562916c146 SHA1: ec51d2d8641d9234ccffc0d61a03f8f467205c73 MD5sum: 8ed001a623ae74302d7046e4187a71c7 Description: sommelier base package. This package installs unitfiles and support scripts for sommelier. Homepage: https://chromium.org Built-Using: Bazel Package: cros-sommelier-config Version: 0.11 Architecture: all Depends: libpam-systemd, cros-sommelier Maintainer: The Chromium OS Authors <chromium-os-dev@chromium.org> Priority: optional Section: misc Filename: pool/main/c/cros-sommelier-config/cros-sommelier-config_0.11_all.deb Size: 1246 SHA256: edbba3817fd3cdb41ea2f008ea4279f2e276580d5b1498c942965c3b00b4bff1 SHA1: 762ca85f3f9cea87566f42912fd6077c0071e740 MD5sum: 767a8a8c9b336ed682b95d9dd49fbde5 Description: sommelier config for Chromium OS integration. This package installs default configuration for sommelier. that is ideal for integration with Chromium OS. Homepage: https://chromium.org Built-Using: Bazel Package: cros-sudo-config Version: 0.10 Architecture: all Depends: sudo Maintainer: The Chromium OS Authors <chromium-os-dev@chromium.org> Priority: optional Section: misc Filename: pool/main/c/cros-sudo-config/cros-sudo-config_0.10_all.deb Size: 810 SHA256: d9c1e2b677dadd1dd20da8499538d9ee2e4c2bc44b16de8aaed0f1e747f371a3 SHA1: 07b961e847112da07c6a24b9f154be6fed13cca1 MD5sum: 37f54f1e727330ab092532a5fc5300fe Description: sudo config for Chromium OS integration. This package installs default configuration for sudo to allow passwordless sudo access for the sudo group. Homepage: https://chromium.org Built-Using: Bazel Package: cros-systemd-overrides Version: 0.10 Architecture: all Depends: systemd Maintainer: The Chromium OS Authors <chromium-os-dev@chromium.org> Priority: optional Section: misc Filename: pool/main/c/cros-systemd-overrides/cros-systemd-overrides_0.10_all.deb Size: 10776 SHA256: 7b960a84d94be0fbe5b4969c7f8e887ccf3c2adf2b2dc10b5cb4856d30eeaab5 SHA1: 06dc91e9739fd3d70fa54051a1166c2dfcc591e2 MD5sum: 16033ff279b2f282c265d5acea3baac6 Description: systemd overrides for running under Chromium OS. This package overrides the default behavior of some core systemd units. Homepage: https://chromium.org Built-Using: Bazel Package: cros-ui-config Version: 0.11 Architecture: all Depends: cros-adapta, dconf-cli, fonts-croscore, fonts-roboto Maintainer: The Chromium OS Authors <chromium-os-dev@chromium.org> Priority: optional Section: misc Filename: pool/main/c/cros-ui-config/cros-ui-config_0.11_all.deb Size: 1280 SHA256: bc1c5513ab67c003a6c069d386a629935cd345b464d13b1dd7847822f98825f3 SHA1: 4193bd92f9f05085d480de09f2c15fe93542f272 MD5sum: 7e95b56058030484b6393d05767dea04 Description: UI integration for Chromium OS This package installs default configuration for GTK+ that is ideal for integration with Chromium OS. Homepage: https://chromium.org Built-Using: Bazel Package: cros-unattended-upgrades Version: 0.10 Architecture: all Depends: unattended-upgrades Maintainer: The Chromium OS Authors <chromium-os-dev@chromium.org> Priority: optional Section: misc Filename: pool/main/c/cros-unattended-upgrades/cros-unattended-upgrades_0.10_all.deb Size: 1008 SHA256: 33057294098edb169e03099b415726a99fb1ffbdf04915a3acd69f72cf4c84e8 SHA1: ec575f7222c5008487c76e95d073cc81107cad0b MD5sum: ae30c3a11da61346a710e4432383bbe0 Description: Unattended upgrades config. This package installs an unattended upgrades config for Chromium OS guest containers. Homepage: https://chromium.org Built-Using: Bazel Package: cros-wayland Version: 0.10 Architecture: all Maintainer: The Chromium OS Authors <chromium-os-dev@chromium.org> Priority: optional Section: x11 Filename: pool/main/c/cros-wayland/cros-wayland_0.10_all.deb Size: 886 SHA256: 06d26a150e69bda950b0df166328a2dae60ac0a0840f432b26dc127b842dd1ef SHA1: 48bd118c497b0a4090b126d7c3d8ec3aacced504 MD5sum: a495d16e5212535571adfd7820b733c2 Description: Wayland extras for virtwl in Chromium OS. This package provides config files and udev rules to improve the Wayland experience under CrOS. Homepage: https://chromium.org Built-Using: Bazel Conclusion

    It is quite neat that Chrome OS uses machine containers with LXD to maintain a Linux installation.

    Apart from the apparent benefits of the Chromebook users, it makes sense to have a look at the implementation in order to figure out how to create a sort of lightweight Virtualbox clone (ability to run a desktop environment of any Linux distribution) that uses containers and LXD.

    Simos Xenitellishttps://blog.simos.info/
    Categories: Linux

    Sina Mashek: Setting up Samba on Solus

    Planet Ubuntu - Wed, 05/09/2018 - 15:00

    Solus comes with Samba installed by default, as I am sure some other distributions do too. Last time I dealt with Samba, I wanted to gouge my eyes out, it was so complicatedly awful. This time, however, it was extremely simple.

    If you’re new to the command line, please remember that the dollar sign ($) is not part of the command. It denotes that I’m running as a regular user. (Root console has a hash mark (#) instead, on most default setups.)

    First thing I needed to do was copy smb.conf to /etc/samba/smb.conf:

    $ sudo cp /usr/share/defaults/samba/smb.conf /etc/samba/smb.conf

    Originally, I had tried to create my Samba password before doing that, but it tossed a ton of errors. I ended up doing that as the last step.

    Since I don’t want Samba user to be the same as mine, I decided to use a different name. That user must also exist as a Linux user, so we have t ofirst add that:

    $ sudo useradd -s /sbin/nologin -m share

    The command above creates the user “share” with a default home directory of /home/share and no shell, since it doesn’t need to be able to log in via SSH.

    Now we’ll edit /etc/samba/smb.conf to include the location to our shared folder. I recommend adding this to the end of the file, though I added mine after the [homes] section:

    [Share] comment = Share Folder path = /home/share browsable = yes read only = no

    Since this is temporary and I plan on removing these things later, I did not bother commenting out the Printer section, which I usually do. I don’t own a printer and there’s no reason for it to try and share one. You can if you want; it’s your configuration file, after all.

    I ran testparm to make sure that there were no typoes. It checks the smb.conf for any errors:

    $ sudo testparm Load smb config files from /usr/share/defaults/samba/smb.conf rlimit_max: increasing rlimit_max (10000) to minimum Windows limit (16384) Processing section "[homes]" Processing section "[homes]" Processing section "[share]" Loaded services file OK. Server role: ROLE_STANDALONE Press enter to see a dump of your service definitions

    If there are no errors, it should look similar to what’s above. You can either press “enter” or “ctrl+c” — either is up to you.

    Since everything is working as intended, we’ll finally add the Samba password with smbpasswd before restarting Samba:

    $ sudo smbpasswd -a share New SMB password: Retype new SMB password: Added user share.

    If all goes well, it should look like the above. Let’s restart Samba, then test on a Windows computer:

    $ sudo systemctl restart smb

    Note: In Solus, the Samba daemon we went to restart is smb, but the name might vary between distributions.

    On the Windows machine, I visited my computer by opening the file explorer and typing \\REMEDIOS in the address box, then pressed “enter.” I was presented with the folder “share”, and was able to log in with the username share and the password I set!

    This is a very basic Samba setup, so I encourage you to check out the SambaWiki for more info.

    Categories: Linux

    Mark Shuttleworth: Cue the Cosmic Cuttlefish

    Planet Ubuntu - Tue, 05/08/2018 - 08:45

    With our castor Castor now out for all to enjoy, and the Twitterverse delighted with the new minimal desktop and smooth snap integration, it’s time to turn our attention to the road ahead to 20.04 LTS, and I’m delighted to say that we’ll kick off that journey with the Cosmic Cuttlefish, soon to be known as Ubuntu 18.10.

    Each of us has our own ideas of how the free stack will evolve in the next two years. And the great thing about Ubuntu is that it doesn’t reflect just one set of priorities, it’s an aggregation of all the things our community cares about. Nevertheless I thought I’d take the opportunity early in this LTS cycle to talk a little about the thing I’m starting to care more about than any one feature, and that’s security.

    If I had one big thing that I could feel great about doing, systematically, for everyone who uses Ubuntu, it would be improving their confidence in the security of their systems and their data. It’s one of the very few truly unifying themes that crosses every use case.

    It’s extraordinary how diverse the uses are to which the world puts Ubuntu these days, from the heart of the mainframe operation in a major financial firm, to the raspberry pi duck-taped to the back of a prototype something in the middle of nowhere, from desktops to clouds to connected things, we are the platform for ambitions great and small. We are stewards of a shared platform, and one of the ways we respond to that diversity is by opening up to let people push forward their ideas, making sure only that they are excellent to each other in the pushing.

    But security is the one thing that every community wants – and it’s something that, on reflection, we can raise the bar even higher on.

    So without further ado: thank you to everyone who helped bring about Bionic, and may you all enjoy working towards your own goals both in and out of Ubuntu in the next two years.

    Categories: Linux

    Mark Shuttleworth: Cue the Cosmic Cuttlefish

    Planet Ubuntu - Tue, 05/08/2018 - 08:45

    With our castor Castor now out for all to enjoy, and the Twitterverse delighted with the new minimal desktop and smooth snap integration, it’s time to turn our attention to the road ahead to 20.04 LTS, and I’m delighted to say that we’ll kick off that journey with the Cosmic Cuttlefish, soon to be known as Ubuntu 18.10.

    Each of us has our own ideas of how the free stack will evolve in the next two years. And the great thing about Ubuntu is that it doesn’t reflect just one set of priorities, it’s an aggregation of all the things our community cares about. Nevertheless I thought I’d take the opportunity early in this LTS cycle to talk a little about the thing I’m starting to care more about than any one feature, and that’s security.

    If I had one big thing that I could feel great about doing, systematically, for everyone who uses Ubuntu, it would be improving their confidence in the security of their systems and their data. It’s one of the very few truly unifying themes that crosses every use case.

    It’s extraordinary how diverse the uses are to which the world puts Ubuntu these days, from the heart of the mainframe operation in a major financial firm, to the raspberry pi duck-taped to the back of a prototype something in the middle of nowhere, from desktops to clouds to connected things, we are the platform for ambitions great and small. We are stewards of a shared platform, and one of the ways we respond to that diversity is by opening up to let people push forward their ideas, making sure only that they are excellent to each other in the pushing.

    But security is the one thing that every community wants – and it’s something that, on reflection, we can raise the bar even higher on.

    So without further ado: thank you to everyone who helped bring about Bionic, and may you all enjoy working towards your own goals both in and out of Ubuntu in the next two years.

    Categories: Linux

    Pages

    Subscribe to Bill's Place aggregator - Linux