Planet Debian

Subscribe to Planet Debian feed
Planet Debian - http://planet.debian.org/
Updated: 3 hours 2 min ago

Reproducible builds folks: Reprotest containers are (probably) working, finally

13 July, 2016 - 22:49

Author: ceridwen

After testing and looking at the code for Plumbum, I decided that it wouldn't work for my purposes. When a command is created by something like remote['ls'], it actually looks up which ls executable will be run and uses in the command object an internal representation of a path like /bin/ls. To make it work with autopkgtest's code would have required writing some kind of middle layer that would take all of the Plumbum code that makes subprocess calls, does path lookups, or uses the Python standard library to access OS functions and convert them into shell scripts. Another similar library, sh, has the same problems. I think there's a strong argument that something like Plumbum's or sh's API would be much easier to work with than adt_testbed, and I may take steps to improve it at some point, but for the moment I've focused on getting reprotest working with the existing autopkgtest/adt_testbed API.

To do this, I created a minimalistic shell AST library in _shell_ast.py using the POSIX shell grammar. I omitted a lot of functionality that wasn't immediately relevant for reprotest and simplified the AST in some places to make it easier to work. Using this, it generates a shell script and runs it with adt_testbed.Testbed.execute(). With these pieces in place, the tests succeed for both null and schroot! I haven't tested the rest of the containers, but barring further issues with autopkgtest, I expect they should work.

At this point, my goal is to push the next release out by next week, though as usual it will depend on how many snags I hit in the process. I see the following as the remaining blockers:

  • Test chroot and qemu in addition to null and schroot.

  • PyPi still doesn't install the scripts in virt/ properly.

  • While I fixed part of adt_testbed's error handling, some build failures still cause it to hang, and I have to kill the process by hand.

  • Better user documentation. I don't have time to be thorough, but I can provide a few more pointers.

Norbert Preining: Jonas Jonasson – The Girl Who Saved the King of Sweden

13 July, 2016 - 07:59

Just finished my first book of Jonas Jonasson, a Swedish journalist and author. Most famous for his book The Hundred-Year-Old Man Who Climbed Out the Window and Disappeared, but author of two others. The one I read was The Girl Who Saved the King of Sweden, which strange enough became in German Die Analphabetin die rechnen konnte (The analphabet who could compute).

The story recounts the countless turns the life of Nombeko Mayeki, a black girl born in Soweto as latrine cleaner, who manages to save the Swedish king as well as most of the world from an atomic desaster by first getting driven over by a drunkard of South African nuclear bomb engineer, then meeting a clique of three Chinese sisters excelling in faking antiquities, and two Mossad agents. With the (unwilling) help of those agents she escapes to Sweden (including the atomic bomb) where she meets twins of a psychotic father who brought them up as one child so that the spare one can eradicate the Swedish monarchy. After many twists and setbacks, including several meetings with the Chinese premier Hu Jintao, she finally manages to get rid of the atomic bomb, get her “undercover” twin a real identity, and set up a proper life – ah, and not to forget, save the King of Sweden!

A fast paced, surprisingly funny and lovely story about how little things can change our lives completely.

Steinar H. Gunderson: Cisco WLC SNMP password reset

13 July, 2016 - 05:00

If you have a Cisco wireless controller whose admin password you don't know, and you don't have the right serial cable, you can still reset it over SNMP if you forgot to disable the default read/write community:

snmpset -Os -v 2c -c private 192.168.1.1 1.3.6.1.4.1.14179.2.5.5.1.3.5.97.100.109.105.110 s foobarbaz

Thought you'd like to know. :-P

(There are other SNMP-based variants out there that rely on the CISCO-CONFIG-COPY-MIB, but older versions of the WLc software doesn't suppport it.)

Olivier Grégoire: Seventh week: create a new architecture and send a lot of information

12 July, 2016 - 23:57

At the begin of this week, I thought my architecture needed to be closer to the call . The goal was to create one class per call to save the different information. With this method, I only need to call the instance who I am interested and I can easly pull the information.
So, I began to rewrite my architecture on the daemon to create an instance of my class link directly with the callID.
After implementing it, I was really disappointed. This class was hardly to call from the upper software layers. Indeed, I didn’t know what is the current call display on my client.
I change my mind and I rewrite the architecture again. I observed the information I want to pull (frame rate, bandwidth, resolution…) and they are all generating in my daemon. Therefore, it will update every time something change in the client. So, I just need to catch it and send it to the upper software layers. My new architecture is simply a singleton because I just need one instance and I need to pull it from everywhere in my program.


Beyond that, I wanted to pull some information about the video (frame rate, resolution, codec for the local and remote computer). So, I looked to understand how the frame generate work. Now I can pull:
-Local and remote video codec
-Local and remote frame rate
-Remote audio codec
-Remote resolution
-CallID

———————

Next week, I will begin with working on creating an API on the client library. After that, I will continue to retrieve other information.

Dirk Eddelbuettel: RProtoBuf 0.4.4, and new JSS paper

12 July, 2016 - 08:43

A new release 0.4.4 of RProtoBuf is now on CRAN, and corresponds to the source archive for the Journal of Statistical Software paper about RProtoBuf as JSS vol71 issue 02. The paper is also included as a pre-print in the updated package.

RProtoBuf provides R bindings for the Google Protocol Buffers ("Protobuf") data encoding library used and released by Google, and deployed as a language and operating-system agnostic protocol by numerous projects.

This release brings small cleanups as well as build-system updates for the updated R 3.3.0 infrastructure based on g++ 4.9.*.

Changes in RProtoBuf version 0.4.4 (2016-07-10)
  • New vignette based on our brand-new JSS publication (v71 i02)

  • Some documentation enhancements were made, as well as other minor cleanups to file modes and operations

  • Unit-test vignette no longer writes to /tmp per CRAN request

  • The new Windows toolchain (based on g++ 4.9.*) is supported

CRANberries also provides a diff to the previous release. The RProtoBuf page has an older package vignette, a 'quick' overview vignette, a unit test summary vignette, and the pre-print for the JSS paper. Questions, comments etc should go to the GitHub issue tracker off the GitHub repo.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Mateus Bellomo: Get presence from buddy’s

12 July, 2016 - 08:19

 

Now it’s also implemented the functionality that allows a user to see his contacts presence. At first week I’ve implemented only the Telepathy part of this methods and back then I didn’t comprehend that this information would come in the form of a NOTIFY SIP message. I also needed to use the SUBSCRIPTION mechanism properly so the presence server could send me the NOTIFY message.

To be able to create those messages was necessary a better understanding of resip/stack, resip/recon and resip/dum API’s.  Not that I master this libraries now, but at least I’m not totally lost anymore =)

Looking into this libraries I could see how much work was done by all of resiprocate contributors (and I imagine I don’t even saw the tip of the iceberg). There is so many features ready for use that now I think twice before start implementing something.

Since I didn’t find any reference explicitly showing the contact’s status in RFC3863 [1], I got this information by changing a contact presence (in a different machine logged in Jitsi [2]) and looking into the NOTIFY message received at resiprocate.

Follow some images about contact’s presence at Empathy:

 

Online status

 

 

Offline status Busy – DND status Away status In a meeting status Unknow status

[1] https://tools.ietf.org/html/rfc3863

[2] https://jitsi.org/


Joey Hess: twenty years of free software -- part 13 past and future

12 July, 2016 - 07:07

This series has focused on new projects. I could have said more about significant work that didn't involve starting new projects. A big example was when I added dh to debhelper, which led to changes in a large percentage of debian/rules files. And I've contributed to many other free software projects.

I guess I've focused on new projects becuase it's easier to remember things I've started myself. And because a new project is more wide open, with more scope for interesting ideas, especially when it's free software being created just because I want to, with no expectations of success.

But starting lots of your own projects also makes you responsible for maintaining a lot of stuff. Ten years ago I had dozens of projects that I'd started and was still maintaining. Over time I started pulling away from Debian, with active projects increasingly not connected with it. By the end, I'd left and stopped working on the old projects. Nearly everything from my first decade in free software was passed on to new maintainers. It's good to get out from under old projects and concentrate on new things.

I saved propellor for last in this series, because I think it may point toward the future of my software. While git-annex was the project that taught me Haskell, propellor's design is much more deeply influenced by the Haskell viewpoint.

Absorbing that viewpoint has itself been a big undertaking for me this decade. It's like I was coasting along feeling at the top of my game and wham got hit by the type theory bus. And now I see that I was stuck in a rut before, and begin to get a feeling of many new possibilities.

That's a good feeling to have, twenty years in.

Niels Thykier: mips64el added to Debian testing

12 July, 2016 - 02:09

Today, we have completed our first Britney run with mips64el enabled in testing. 

At the current time, the set of packages in mips64el are not very connected (and you probably cannot even install build-essential yet[1]). Hopefully this will change over the next few days. For now, Britney does not enforce installability of packages on mips64el in general, so do not expect the architecture to be stable at the moment.

Cheat sheet for package maintainers:

  • Issues with builds (only) on mips64el are not blockers for testing migration (nor RC yet).
    • Such bugs should be filed as “important” for now (unless they also affect a release architecture, in which case you should still make it an RC bug)
  • Your package be an older version on mips64el compared to other architectures.
  • Britney may decide to break your package on mips64el if it means something else can migrate on a release architecture.

We will slowly remove these special cases for mips64el as it matures in testing.

 

[1]  Update on this: mips64el currently does not have a libc library yet, so build-essential is definitely not installable at the moment.  It will hopefully migrate very soon.


Filed under: Debian, Release-Team

Jonathan Dowland: iPod

11 July, 2016 - 23:26

iPod with rockbox

open iPod with iFlash

It's been four years since I last wrote about music players. In the meantime ⅔ of my Sansa Fuzes broke, and the third does not have great rockbox support. I've also been using a Sansa Clip+ (a leaving present from my last job, thanks again!) and a Sansa Clip Zip. Unfortunately Sandisk's newer Sansa devices (Sport, Jam - the only ones still in production) are not supported by Rockbox.

The Clips have been very reliable and sturdy players, but I have missed the larger display of the Fuze. Since I've been exploring HD audio I've also been interested in something with an A/D converter that can handle it. I also still wish to carry my entire music library around with me, which limits my options.

I decided to try an iPod. The older iPods had a Wolfson-manufacturered ADC which had a good reputation and supported (in headline terms at least) 24/48. The iPod colour (aka "4th gen") and subsequent models have a large colour display. The click-wheel interface is also very nice. Apple have now discontinued the "classic" iPod and their second hand value has greatly increased, but I managed to get an older 5th generation model ("video", with a base capacity of 30G) whilst trading in some unwanted DVDs. The case was scratched to heck but a replacement was readily and cheaply available from auction sites.

Rockbox support in these iPods is pretty good, and you can mod the hardware to support CF or SD cards with kits such as the iFlash kits by Tarkan Akdam, which I picked up, along with a new 128G SD card.

Unfortunately I have found writing to the iPod to be very poor with Rockbox, but it's fine for playback, and booting the iPod in OF or DFU mode is very easy and works reliably.

Whilst Rockbox on the iPod works pretty well, installing it is far harder than on the Sandisk Sansa devices. The difficulty in my case is because rockbox requires a PC-formatted iPod to install, and I had a Mac-formatted one. I couldn't find a way to convert the iPod to PC format using a Mac. I tried doing so on a PC but for some reason the PC wasn't playing ball so I gave up after a few hours. In the end I assembled the filesystem by hand using dd(1) and dumps of partition tables from other people's iPods, via a Linux machine. This was enough to convince iTunes on Mac to restore it's hidden partition and boot software without reverting back to a Mac disklabel format.

Daniel Pocock: Let's Encrypt torpedoes cost and maintenance issues for Free RTC

11 July, 2016 - 20:34

Many people have now heard of the EFF-backed free certificate authority Let's Encrypt. Not only is it free of charge, it has also introduced a fully automated mechanism for certificate renewals, eliminating a tedious chore that has imposed upon busy sysadmins everywhere for many years.

These two benefits - elimination of cost and elimination of annual maintenance effort - imply that server operators can now deploy certificates for far more services than they would have previously.

The TLS chapter of the RTC Quick Start Guide has been updated with details about Let's Encrypt so anybody installing SIP or XMPP can use Let's Encrypt from the outset.

For example, somebody hosting basic Drupal or Wordpress sites for family, friends and small community organizations can now offer them all full HTTPS encryption, WebRTC, SIP and XMPP without having to explain annual renewal fees or worry about losing time in their evenings and weekends renewing certificates manually.

Even people who were willing to pay for a single certificate for their main web site may have snubbed their nose at the expense and ongoing effort of having certificates for their SMTP mail server, IMAP server, VPN gateway, SIP proxy, XMPP server, WebSocket and TURN servers too. Now they can all have certificates.

Early efforts at SIP were doomed without encryption

In the early days, SIP messages would be transported across the public Internet in UDP datagrams without any encryption. SIP itself wasn't originally designed for NAT and a variety of home routers were created with "NAT helper" algorithms that would detect and modify SIP packets to try and work through NAT. Sadly, in many cases these attempts to help actually clash with each other and lead to further instability. Conversely, many rogue ISPs could easily detect and punish VoIP users by blocking their calls or even cutting their DSL line. Operating SIP over TLS, usually on the HTTPS port (TCP port 443) has been an effective way to quash all of these different issues.

While the example of SIP is one of the most extreme, it helps demonstrate the benefits of making encryption universal to ensure stability and cut out the "man-in-the-middle", regardless of whether he is trying to help or hinder the end user.

Is one certificate enough?

Modern SIP, XMPP and WebRTC require additional services, TURN servers and WebSocket servers. If they are all operated on port 443 then it is necessary to use different hostnames for each of them (e.g. turn.example.org and ws.example.org. Each different hostname requires a certificate. Let's Encrypt can provide those additional certificates too, without additional cost or effort.

The future with Let's Encrypt

The initial version of the Let's Encrypt client, certbot, fully automates the workflow for people using popular web servers such as Apache and nginx. The manual or certonly modes can be used for other services but hopefully certbot will evolve to integrate with many other popular applications too.

Currently, Let's Encrypt only issues certificates to servers running on TCP port 443. This is considered to be a privileged port whereas any port over 1023, including the default ports used by applications such as SIP (5061), XMPP (5222, 5269) and TURN (5349), are not privileged ports. As long as Let's Encrypt maintains this policy, it is necessary to either run a web server for the domain associated with each certificate or run the services themselves on port 443. Running the services themselves on port 443 turns out to be a good idea anyway as it ensures that RTC services can be reached through HTTP proxy servers who fail to let the HTTP CONNECT method access any other ports.

Many configuration tasks are already scripted during the installation of packages on a GNU/Linux distribution (such as Debian or Fedora) or when setting up services using cloud images (for example, in Docker or OpenStack). Due to the heavily standardized nature of Let's Encrypt and the widespread availability of the tools, many of these package installation scripts can be easily adapted to find or create Let's Encrypt certificates on the target system, ensuring every service is running with TLS protection from the minute it goes live.

If you have questions about Let's Encrypt for RTC or want to share your experiences, please come and discuss it on the Free-RTC mailing list.

Dirk Eddelbuettel: Rcpp now used by over 700 CRAN packages

11 July, 2016 - 18:41

Earlier this morning, Rcpp reached another milestone: 701 packages on CRAN now depend on it (as measured by Depends, Imports and LinkingTo declarations). The graph is on the left depicts the growth of Rcpp usage over time.

Rcpp cleared 300 packages in November 2014. It passed 400 packages in June of last year (when I only tweeted about it), 500 packages in late October and 600 packages exactly four months ago in March. The chart extends to the very beginning via manually compiled data from CRANberries and checked with crandb. Then next part uses manually saved entries, and the final and largest part of the data set was generated semi-automatically via a short script appending updates to a small file-based backend. A list of packages using Rcpp is kept on this page.

Also displayed in the graph is the relative proportion of CRAN packages using Rcpp. The four per-cent hurdle was cleared just before useR! 2014 where I showed a similar graph (as two distinct graphs) in my invited talk. We passed five percent in December of 2014, six percent last July, seven percent just before Christmas and now criss-crosses 8 eight percent, or a little less than one in twelve R packages.

700 user packages is a really large and humbling number. This places quite some responsibility on us in the Rcpp team as we continue to try our best try to keep Rcpp as performant and reliable as it has been.

So with that a very big Thank You! to all users and contributors of Rcpp for help, suggestions, bug reports, documentation or, of course, code.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Simon Désaulniers: [GSOC] Week 5&6 Report

11 July, 2016 - 01:06

During week 5 and 6, I have been to the debian conference 2016. It was really interesting meeting with a lot of people all so involved in Debian.

Key signing party

Each year, this is a really important tradition: people gather together and exchange GPG public key fingerprint and sign each other’s keys. This contributes greatly to the growth of the web of trust.

I did exchange public key fingerprint with others. It was the first opportunity become more connected in the PGP web of trust. I think this is something that needs to make its way to the less technical people so that everyone can benefit from the network privacy features. There is support for some mail clients like Thunderbird, but I think there is still work to do there and mostly there is work to do about the opinion or point of view people have about encryption ; people don’t care enough and they don’t really know what encryption can do for them (digital signature, trust and privacy).

Ring now part of Debian

During the first week at debcamp, Alexandre Viau, an employee at Savoir-Faire Linux and a also a Debian developer (DD for short), has packaged Ring for Debian. Users can now install Ring like so:

$ sudo apt-get install ring

This is an important moment as more people are now going to easily try Ring and potentially contribute to it.

Presentating Ring

Alexandre Viau and I have been thinking about presenting Ring at debconf 2016. We finally did it.

  Your browser does not support the video tag.

Ritesh Raj Sarraf: Leprosy in India

11 July, 2016 - 01:06

During my recent travel, I had quite a long layover at the Doha International Airport in Qatar. While killing time, I watched an interesting programme on the Al Jazeera network.

The program aired on Al Jazeera is Lifelines. This special episode I watched, covered about "Leprosy in India". After having watched the entire programme, I felt the urge to blog about it.

First of all, it was quite depressing to me, to know through the programme, that the Govt. of India had officially marked "Leprosy" eradicated from India in 2005. As per Wikipedia, "Globally in 2012, the number of chronic cases of leprosy was 189,000, down from some 5.2 million in the 1980s. The number of new cases was 230,000. Most new cases occur in 16 countries, with India accounting for more than half." 

Of the data presented on Lifelines, they just covered a couple of districts from 2 States (of the 28+ States) of India. So, with many states remaining, and unserveyed, and uncounted, we are far away from making such statements.

Given that the Govt., on paper, has marked Leprosy eradicated; so does WHO. Which means that there is no more funding to help people suffering from the disease. And with no Govt. (or International) funding, it is a rather disappointing situation.

I come from a small town on the Indo-Nepal intl. border, named Raxaul. And here, I grew up seeing many people who suffered from Leprosy. As a child, I never much understood the disease, because as is mentioned in the programme, I was told it was a communicable disease. Those suffering, were (and are) tagged as Untouchables (Hindi:अछूत). Of my small town, there was and still is a sub-town, named Sunderpur. This town houses patients suffering from Leprosy, from around multiple districts closeby. I've never been there, but have been told that it is run by an NGO, and helps patients fight the disease.

Lifelines also reported that fresh surveys done by the Lepra society, just a 3 day campaign, resulted in 3808 new cases of people suffering from Leprosy. That is a big number, given accessibility to small towns only happens once a week on market day. And in 3 days the team hardly covered a couple of district towns.

My plea to the Media Houses of India. Please spend some time to look beyond the phony stuff that you mostly present. There are real issues that could be brought to a wider audience. As for the government, it is just depressing to know how rogue some/most of your statements are.

Categories: Keywords: Like: 

Ritesh Raj Sarraf: Leprosy in India

11 July, 2016 - 01:06

During my recent travel, I had quite a long layover at the Doha International Airport in Qatar. While killing time, I watched an interesting programme on the Al Jazeera network.

The program aired on Al Jazeera is Lifelines. This special episode I watched, covered about "Leprosy in India". After having watched the entire programme, I felt the urge to blog about it.

First of all, it was quite depressing to me, to know through the programme, that the Govt. of India had officially marked "Leprosy" eradicated from India in 2005. As per Wikipedia, "Globally in 2012, the number of chronic cases of leprosy was 189,000, down from some 5.2 million in the 1980s. The number of new cases was 230,000. Most new cases occur in 16 countries, with India accounting for more than half." 

Of the data presented on Lifelines, they just covered a couple of districts from 2 States (of the 28+ States) of India. So, with many states remaining, and unserveyed, and uncounted, we are far away from making such statements.

Given that the Govt., on paper, has marked Leprosy eradicated; so does WHO. Which means that there is no more funding to help people suffering from the disease. And with no Govt. (or International) funding, it is a rather disappointing situation.

I come from a small town on the Indo-Nepal intl. border, named Raxaul. And here, I grew up seeing many people who suffered from Leprosy. As a child, I never much understood the disease, because as is mentioned in the programme, I was told it was a communicable disease. Those suffering, were (and are) tagged as Untouchables (Hindi:अछूत). Of my small town, there was and still is a sub-town, named Sunderpur. This town houses patients suffering from Leprosy, from around multiple districts closeby. I've never been there, but have been told that it is run by an NGO, and helps patients fight the disease.

Lifelines also reported that fresh surveys done by the Lepra society, just a 3 day campaign, resulted in 3808 new cases of people suffering from Leprosy. That is a big number, given accessibility to small towns only happens once a week on market day. And in 3 days the team hardly covered a couple of district towns.

My plea to the Media Houses of India. Please spend some time to look beyond the phony stuff that you mostly present. There are real issues that could be brought to a wider audience. As for the government, it is just depressing to know how rogue some/most of your statements are.

Categories: Keywords: Like: 

Joey Hess: twenty years of free software -- part 12 propellor

11 July, 2016 - 00:29

Propellor is my second big Haskell program. I recently described the motivation for it like this, in a proposal for a Linux.Conf.Au talk:

The configuration of Linux hosts has become increasingly declarative, managed by tools like puppet and ansible, or by the composition of containers. But if a server is a collection of declarative properties, how do you make sure that changes to that configuration make sense? You can test them, but eventually it's 3 AM and you have an emergency fix that needs to go live immediately.

Data types to the rescue! While data types are usually used to prevent eg, combining an Int and a Bool, they can be used at a much more abstract level, for example to prevent combining a property that needs a Debian system with a property that needs a Red Hat system.

Propellor leverages Haskell's type system to prove the consistency of the properties it will apply to a host.

The real origin story though, is that I wanted to finally start using configuration management, but the tools for it all seemed very complicated and built on shakey foundations (like piles of yaml), and it seemed it would be easier to write my own than deal with that. Meanwhile, I had Haskell burning a hole in my pocket, ready to be used in a second large project after git-annex.

Propellor has averaged around 2.5 contributions per month from users since it got started, but increasing numbers recently. That's despite having many fewer users than git-annex, which remember gets perhaps 1 patch per month.

Of course, I've "cheated" by making sure that propellor's users know Haskell, or are willing to learn some. And, propellor is very compositional; adding a new property to it is not likely to be complicated by any of the existing code. So it's easy to extend, if you're able to use it.

At this point propellor has a small community of regular contributors, and I spend some pleasant weekend afternoons reviewing and merging their work.

Much of my best work on propellor has involved keeping the behavior of the program the same while making its types better, to prevent mistakes. Propellor's core data types have evolved much more than in any program I worked on before. That's exciting!

Next: ?twenty years of free software -- part 13 past and future

Simon Désaulniers: [GSOC] Week 3&4 Report

11 July, 2016 - 00:12

I have finally made a version of the queries code that can viably be integrated into the master branch of OpenDHT. I am awaiting my mentor’s approval and/or comments.

What’s done

Queries. The library will provide the additional following functions in its API:

void get(InfoHash id, GetCallbackSimple cb, DoneCallback donecb={}, Value::Filter f = Value::AllFilter(), Where w = {}) {
void query(const InfoHash& hash, QueryCallback cb, DoneCallback done_cb = {}, Query q = {});

The structure Where in the first signature will allow the user to narrow the set of values received through the network those that verify the “where” statement. The Where actually encapsulates a statement of the following SQL-ish form: SELECT * WHERE <some_field>=<some_field_value>.

Also, the DhtRunner::query function will let the user do something similar to what’s explained in the last paragraph, but where the returned data is encapsulated in FieldValueIndex structure instead of Value. This structure has a std::map<Value::Field, FieldValue>. You can think of the FieldValueIndex as a subset of fields of a given Value. The Query structure then allows you to create both Select and Where “statements”.

What’s next
  • Value pagination. I have begun working on this and I now have a more clear idea of the first step to accomplish. I have to redesign the ‘get’ operation callbacks calling process by making a callback execution per SearchNode instead of per Search (list of SearchNode). This will let us properly write the value pagination code with node concurrency in mind. This will therefor make sure we don’t request a value from a node if it doesn’t stores it;
  • Optimizing announce operations;

Bits from Debian: New Debian Developers and Maintainers (May and June 2016)

10 July, 2016 - 22:30

The following contributors got their Debian Developer accounts in the last two months:

  • Josué Ortega (josue)
  • Mathias Behrle (mbehrle)
  • Sascha Steinbiss (satta)
  • Lucas Kanashiro (kanashiro)
  • Vasudev Sathish Kamath (vasudev)
  • Dima Kogan (dkogan)
  • Rafael Laboissière (rafael)
  • David Kalnischkies (donkult)
  • Marcin Kulisz (kula)
  • David Steele (steele
  • Herbert Parentes Fortes Neto (hpfn)
  • Ondřej Nový (onovy)
  • Donald Norwood (donald)
  • Neutron Soutmun (neutrons)
  • Steve Kemp (skx)

The following contributors were added as Debian Maintainers in the last two months:

  • Sean Whitton
  • Tiago Ilieve
  • Jean Baptiste Favre
  • Adrian Vondendriesch
  • Alkis Georgopoulos
  • Michael Hudson-Doyle
  • Roger Shimizu
  • SZ Lin
  • Leo Singer
  • Peter Colberg

Congratulations!

Paul Tagliamonte: SNIff

10 July, 2016 - 20:34

A while back, I found myself in need of two webservers that would terminate TLS (with different rules). I wanted to run some custom code I’d written (which uses TLS peer authentication), and also nginx on port 443.

The best way I figured out how to do this was to write a tool to sit on port 443, and parse TLS Client Hello packets, and dispatch to the correct backend depending on the SNI name.

SNI, or Server Name Indication allows the client to announce (yes over cleartext!) what server it’s looking for, similar to the HTTP Host header. Sometimes, like in the case above, the Host header won’t work, since you’ve already done a TLS handshake by the time you figure out who they’re looking for.

I also spun the Client Hello parser out into its own importable package, just in case someone else finds themselves in this same boat.

The code’s up on github.com/paultag/sniff!

Pages

Creative Commons License ลิขสิทธิ์ของบทความเป็นของเจ้าของบทความแต่ละชิ้น
ผลงานนี้ ใช้สัญญาอนุญาตของครีเอทีฟคอมมอนส์แบบ แสดงที่มา-อนุญาตแบบเดียวกัน 3.0 ที่ยังไม่ได้ปรับแก้