Elsewhere

Bits from Debian: Debian selected to participate in the Google Summer of Code

Planet Debian - Sun, 13/03/2016 - 16:00

For the tenth time running, Debian has been selected as a mentoring organization for the Google Summer of Code (Debian-specific program page), an internship program open to university students aged 18 and up.

Our team of amazing mentors has cooked up an exciting list of projects this year, and we would be glad to have you on board with Debian for one of those summer internships. The student application period will open on March 14 (and close on March 25), but feel free to subscribe to our mailing list and get in touch with our mentors. You can also catch us on our IRC channel #debian-soc.

Categories: Elsewhere

Ingo Juergensmann: Letsencrypt: challenging challenges solved

Planet Debian - Sun, 13/03/2016 - 14:45

A few weeks ago I was wondering in Letsencrypt: challenging challenges about how to setup Letsencrypt when a domain is spread across several virtual machines (VM). One of the possible solutions would be to consolidate everything on one single VM, which is nothing I would like to do. The second option would need to generate the Letsencrypt certs on the webserver and copy over the certs to the appropriate VM on a regular basis or event driven. The third option is to use a network share - and this is what I'm using right now.

So, my setup is as following after I solved the GlusterFS issue with rpcbind binding to all interfaces, although it has been configured to only listen to certain interfaces (solution was: simply remove all NFS related stuff):

On Dom0 (or the host machine) I run GlusterFS as a server on a small 1 GB LVM as part of a replicate with the VM that will do the actual Letsencrypt work: 

Volume Name: le
Type: Replicate
Status: Started
Number of Bricks: 1 x 2 = 2
Transport-type: tcp
Bricks:
Brick1: 192.168.x.254:/srv/gfs/le
Brick2: 192.168.x.1:/srv/gfs/le

This is to ensure that on reboot of the machine every other VM using Letsencrypt certs can mount the GlusterFS share, because the host machine will be there for sure whereas the other VM generating the certs with the letsencrypt.sh script might still be booting. And when the GlusterFS share is missing services will not start on the other VMs because of the missing certs, of course. So, the replica on the virtualization host (Dom0) is only acting as some kind of always-being-available network share, because, well, the other VM will not always be there... for example during a kernel update when a reboot is required.

The same setup is on my mailserver, acting as the second GlusterFS brick of that replica drive. The mailserver hosts the bind9 nameserver as well and I might do something that new domains with Letsencrypt certs get added to my DNSSEC setup as well. Of course, when the letsencrypt.sh script creates or updates the certs, it needs the certs being mounted in that configured location, so I needed to add a line to /etc/fstab: 

192.168.x.254:/le /etc/letsencrypt.sh/certs glusterfs noexec,nodev,_netdev 0 0

Basically the same needs to be done on the other VMs where you want to use the certs as well, but you may want to mount the share as read-only there.

The next step was a little more tricky. When letsencrypt.sh generates new certs, Letsencrypt will contact the webserver for that domain to respond to the ACME challenge. This requires that on each VM you want to use letsencrypt you have to run a webserver. Well, actually at least that there is somewhere a webserver that can answer these requests for that specific domain...

Now, the setup of the webserver (Apache in my case) is like this: 

I'm using the Apache macro module to make it more easy, so I generated two small configs in /etc/apache/conf-available and enabled them bei a2enconf: letsencrypt-proxy.conf to do some setup for proxying the ACME challenges to a common website called acme.example.org. And then letsencrypt-sslredir.conf to setup SSL redirection when everything is in place and the domain can be switched over to HTTPS-only.

letsencrypt-proxy.conf: 

<Macro le_proxy>
     ProxyRequests Off
     <Proxy *>
            Order deny,allow
            Allow from all
     </Proxy>
     ProxyPass /.well-known/acme-challenge/ http://acme.windfluechter.net/
     ProxyPassReverse / http://%{HTTP_HOST}/.well-known/acme-challenge/
</Macro>

letsencrypt-sslredir.conf:

<Macro le_sslredir>
    RewriteEngine on
    RewriteCond %{HTTPS} !=on
    RewriteRule . https://%{HTTP_HOST}%{REQUEST_URI}  [L]
</Macro>

So, after all the setup of a virtual host for Apache looks like this: 

<Macro example.org>
(lots of setup stuff)
</Macro>
<VirtualHost 31.172.31.x:443 [2a01:a700:4629:x::1]:443>
        Header always set Strict-Transport-Security "max-age=31556926; includeSubDomains"
        SSLEngine on
        # letsencrypt certs:
        SSLCertificateFile /etc/letsencrypt.sh/certs/example.org/fullchain.pem
        SSLCertificateKeyFile /etc/letsencrypt.sh/certs/example.org/privkey.pem
        SSLHonorCipherOrder On
    Use example.org
    Use le_proxy
</VirtualHost>
<VirtualHost 31.172.31.x:80 [2a01:a700:4629:x::1]:80>
    Use example.org
    Use le_proxy
    Use le_sslredir
</VirtualHost>

le_sslredir is only needed when you are sure that you want all traffic being redirected to HTTPS. For example when your blog is listed on planet.debian.org or other Planets you might want to omit this from your HTTP config because bug #813313 is not yet solved. 

In the end, when creating a new Letsencrypt cert, you need to add the le_proxy macro to your website, add the domain to letsencrypt.sh config in /etc/letsencrypt.sh/domains.txt and then the scripts will request a new cert from Letsencrypt, handling the ACME challenge stuff via the URL redirection in le_proxy being redirected to your acme.exmaple.org site and finally writes your new cert to the GlusterFS share. From that share you can then use the new cert on all needed VMs, be it your mailserver, webserver or XMPP/SIP server VMs. 

At least this works for me.

Kategorie: DebianTags: DebianSoftwareLetsEncryptServer 
Categories: Elsewhere

Daniel Pocock: Google Summer of Code opportunities for ham radio and SDR

Planet Debian - Sat, 12/03/2016 - 21:39

I've started preparing some ideas for Google Summer of Code projects I'd be willing to help mentor this year and one of them is for ham radio, with a focus on software defined radio (SDR).

Can you help?

If you can help as a co-mentor or simply help refer students for this project please get in touch with me.

Ander the terms of the program students are paid a $US 5,500 stipend by Google and source code is fully published under a genuine free software license .

Details about the project and how students can apply

Students applying for this project are invited to submit two applications, one under the GNU Radio project and another under the Debian Project.

The aim of this project is to make ready-to-run solutions for ham radio enthusiasts.

The typical use case is a ham who has a spare computer in his shack, he should be able to boot the computer from DVD or USB stick using the Debian Ham Radio Live Blend or the GNU Radio Live SDR and have a functional transceiver within a few minutes.

A student may not be able to do everything required for this project in one summer. We are looking for a student who can make any incremental improvement to bring us closer to this goal.

Here are some of the tasks that may be involved:

  • survey the existing GNU Radio samples for ham radio, many are listed on the HamRadio page of the GNU Radio wiki.
  • design user interface improvements for the samples to make them more intuitive to new users and traditional radio operators. Consider how they can interact with Hardware such as a VFO tuning knob, PTT microphone switch and even a morse key.
  • look through the other packages in the Debian Ham Radio metapackage list and consider how they could interact with GNU Radio. In particular, we are interested in the use of message bus solutions, such as ZeroMQ or D-Bus - for example, GNU Radio could send alerts on the bus when incoming signals exceed the squelch threshold. GNU Radio could also receive events over a message bus, for example, patching GPredict to send Doppler shift information.
  • developing and packaging libraries needed to process digital voice transmissions
  • look at how one or more of the samples can be deployed as a Debian package so users can just install the package and have a working radio
Prerequisites

The following experience is highly desirable:

  • ham radio license
  • GNU/Linux skills (Debian or Ubuntu or another distribution like Fedora)
  • use of version control systems (Git)
  • C++ or Python or both
Mentor(s)
  • Daniel Pocock (VK3TQR/M0GLR/HB9FZT)
Application process

To apply

  • please introduce yourself on both the GNU Radio mailing list and the Debian Hams mailing list
  • Fill in the formal application for both GNU Radio and Debian
  • Pick some items from the list above or feel free to suggest another piece of work relevant to this theme. Give us a detailed, week-by-week plan for completing the task over the summer.
  • find at least one other member of the GNU Radio or Debian community who is willing to be a co-mentor on the project. Please try communicating with us over IRC or email and give us examples of your existing work on Github or elsewhere.
Categories: Elsewhere

Bits from Debian: Debian is looking for three interns in the Outreachy Program

Planet Debian - Sat, 12/03/2016 - 20:10

As part of its diversity outreach initiatives, Debian will be participating in the upcoming 12th round (May - August 2016) of Outreachy, an internship program open worldwide to women (cis and trans), trans men and genderqueer people, as well as nationals and residents of the United States of any gender who are Black/African American, Hispanic/Latin@, American Indian, Alaska Native, Native Hawaiian, or Pacific Islander.

Thanks to the generosity of our donors, and specifically of our sponsor Intel who has given us funds specifically for one intern, Debian will be able to welcome three interns this round.

Applications for the program are open until March 22nd, so don't wait up! Debian has a lot of interesting internship opportunities this year. More info about the program is available on the Debian specific program page, as well as on the official website. Feel free to contact the outreach team and mentors on our mailing list or IRC channel #debian-soc in irc.oftc.net

If you want Debian to keep participating in such programs, and expand its outreach efforts, you can donate to one of the organizations supporting the Debian project, or volunteer some time by participating in discussions on our mailing list.

Categories: Elsewhere

Simon Richter: 8192!

Planet Debian - Sat, 12/03/2016 - 19:52

So, finally I've also joined the club.

Categories: Elsewhere

Lars Wirzenius: Not-platform for Debian project leader elections 2016

Planet Debian - Sat, 12/03/2016 - 08:40

After some serious thinking, I've decided not to nominate myself in the Debian project leader elections for 2016. While I was doing that, I wrote the beginnings of a platform, below. I'm publishing it to have a record of what I was thinking, in case I change my mind in the future, and perhaps it can inspire other other people to do something I would like to happen.

Why not run? I don't think I want to deal with the stress. I already have more than enough stress in my life, from work. I enjoy my obscurity in Debian. It allows me to go away for long periods of time, and to ignore any discussions, topics, and people that annoy or frustrate me, if I don't happen to want to tackle them at any one time. I couldn't do that if I was DPL.

NOT a platform for Debian project leader election, 2016

Apart from what the Debian constitution formally specifies, I find that the important duties of the Debian project leader are:

  • Inspire, motivate, and enable the Debian community to make Debian better: to be the grease that makes the machinery run smoother. It is not important that the DPL do things, except to make sure other people can do.
  • Delegate what work can be delegated. The DPL is only one person, and should not be a bottleneck. Anything that can reasonably be delegated should be delegated.
  • Deal with mundane management tasks. This includes spending Debian money when it makes things easier, such as by funding sprints.
  • Represent the project in public, or find people to do that in specific cases.
  • Help resolve conflicts within the project.

I do not feel it is the job of the DPL to set goals for the project, technical or otherwise, any more than any other member of the project. Such goals tend to best come from enthusiastic individual developer who want something and are willing to work on it. The DPL should enable such developers, and make sure they have what they need to do the work.

My plan, if elected
  1. Keep Debian running. Debian can run for a long time effectively on autopilot, even if the DPL vanishes, but not indefinitely. At minimum, the DPL should delegate the secretary and technical committee members, and decide on how money should be spent. I will make sure this minimum level is achieved.

  2. While I have no technical goals to set for the project, I have an organisational one. I believe it is time for the project to form a social committee whose mandate is to step in and help resolve conflicts in their early stages, before they grow big enough that the DPL, the tech-ctte, listmasters, or the DAM needs to involved. See below for more details on this. If I am elected, I will do my best to get a social committee started, and I will assume that any vote for me is also a vote for a social committee.

Social committee

(Note: It's been suggested that this is a silly name, but I haven't had time to come up with anything better. I already rejected "nanny patrol".)

We are a big project now. Despite our reputation, we are a remarkably calm project, but there are still occasional conflicts, and some of them spill out into our big mailing lists. We are not very good, as a project, in handling such situations.

It is not a new idea, but I think its time has come, and I propose that we form a new committee, a social committee, whose job is to help de-escalate conflict situations while they are still small conflicts, to avoid them growing into big problems, and to help resolve big conflicts if they still happen.

This is something the DPL has always been doing. People write to the DPL to ask for mediation, or other help, when they can't resolve a situation by themselves. We also have the technical committee, listmasters, GRs, and the expulsion process defined by the DAM. These are mostly heavy-weight tools and by the time it's time to consider their use, it's already too late to find a good solution.

Having the DPL do this alone puts too much pressure on one person. We've learnt that important tasks should generally be handled by teams rather than just one person.

Thus, I would like us to have a social committee that:

  • is reasonably small, like the technical committee
  • attempts to resolve conflicts at an early stage
  • is delegated by the DPL to have authority to do this
  • doesn't necessarily have direct authority to remove people from mailing lists, IRC channels, or expel them from the project, but has authority suggest such measures to the appropriate team
  • may do other things, such as educate people on how to resolve conflicts constructively themselves, or deal with chronic conflicts in addition to acute flare-ups
About me

I've been a Debian developer since 1996. I've been retired twice, while I spent large amounts of time on other things. I haven't been a member of any important team in Debian, but I've been around long enough that I know many people, and have a reasonable understanding of how the projects works.

Categories: Elsewhere

Pages

Subscribe to jfhovinne aggregator - Elsewhere