Re: Debian services and Debian infrastructure
On Wed, Jan 22, 2014 at 11:07:49PM +0100, Tollef Fog Heen wrote: Since we discussed that back in June, you added 'providing an OpenStack cloud' on the DSA radar (it noticed that it was mentioned in the 'just starting' category of DSA meeting minutes). It's sgran who's been thinking about how to do this, but afaik he's seen close to zero interest from developers for it, so it's not happened yet. I don't think we need anything from the DPL as such, but if people are actually interested in something like this happening, saying so would be a good start. The lack of feedback worries me a bit, since one one hand it seems like you're pushing quite hard for a cloud and all that, yet we're not seeing a user demand. It could be that people don't approach DSA for whatever reason (if so, we should fix that), but doing lots of work for something we don't know if it's needed doesn't sound like a good use of our time. You're quite right on this. On the other hand, as a random DD, I wouldn't have dared asking DSA to set up a sort of Debian private cloud (which I think would be a good idea in general) without knowing beforehand that DSA had at least some interest in the idea. This is not because I'm scared of approaching DSA or anything such, but because I know that setting up such an infra could be a lot of work. In general, Due to the way improvements are usually achieved in Debian, I'm much more likely to ask fellow DDs to implement small changes (better if I've patches to propose) than to ask them to do a lot of work for my needs. But I certainly understand that DSA is not willing to work on something substantial until you know there is enough demand to make it worth. So, in the end, this sounds like a good match-making situation. If you're worried about demand how about mentioning this in a future DSA mail to d-d-a? (No, I don't think this thread is enough visibility, especially considering the conflictual parts it went through.) Just ask people that would potentially use this service to let you know. I, for one thing, would be interested in something like this. To be clear, I don't have anything which is currently *waiting* for this. Looking back at the services I've recently worked on in Debian: it wouldn't have been a good fit for sources.d.n (due to the large storage requirement), but it would've been for the initial experimental phase of pts.d.n and possibly (depending on how difficult it'll be to set up VMs) also for fire-and-forget VMs we have used in the past as build nodes for BSPs. Just my 0.02 EUR, Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Debian services and Debian infrastructure
On Wed, 22 Jan 2014, Tollef Fog Heen wrote: 2) the alternative is that they give up on the idea, or host it themselves, which makes it harder to work collaboratively on the service, and results in services that have a single maintainer (or none, in the end). How does having a random VM running in a cloud somewhere make that service easier to integrate into the wider debian.org setup? It means those people who want to experiment get to ask a VM at some predefined places where various parties can monitor who is asking and what their projects are. think it does; what does is the first point: talk to us so we can figure out what works for both sides. Especially given you want to give root to developers on those VMs, there's absolutely nothing that points in a direction of those VMs being more integrateable than a service developed on a developer's own laptop (in a VM or in their regular environment). Indeed, but it gives others (including DSA) an opportunity to chime in sooner. Another requirement is that the developers should have root access on the virtual machine, so that it's easy to try various options without DSA intervention (remember: this is about developement/beta testing, not about running the service in a super-stable, production mode). Who's then to ensure that machine is secured and kept up to date with security patches and doesn't become a source of spam? Sorry to say, but most developers are not good sysadmins and they do not have the tools and infrastructure set up to do systems maintenance well. For this to be an option at all, we'd want to sandbox the machines heavily enough that they will be less attractive machines to develop on than a developer's own laptop. What kind of restrictions do you expect to have to set up? I can imagine some restrictions on outgoing mails (like Amazon VM do by default) but what else could impeded the abilitiy to develop a new service? It's sgran who's been thinking about how to do this, but afaik he's seen close to zero interest from developers for it, so it's not happened yet. I don't think we need anything from the DPL as such, but if people are actually interested in something like this happening, saying so would be a good start. I would be interested by it. I would have used it for pts.debian.net (instead of the Amazon VM we have now). And later, I would like us to be able to use a Debian cloud to automatize the rebuild of reverse dependencies with a set of updated packages. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140123082414.gd3...@x230-buxy.home.ouaza.com
Re: Debian services and Debian infrastructure
]] Stefano Zacchiroli So, in the end, this sounds like a good match-making situation. If you're worried about demand how about mentioning this in a future DSA mail to d-d-a? (No, I don't think this thread is enough visibility, especially considering the conflictual parts it went through.) Just ask people that would potentially use this service to let you know. It was mentioned in our sprint report from last June and has been in the minutes posted later. I don't recall anybody (apart from Lucas) saying at anything at all about it, on the list or in other forums such as IRC. Yes, we could have mentioned it on d-d-a too, but given it's posted both here and mentioned in a Debian news mailing, I think I think it's indicative that there's no great demand based on us not seeing any responses. If people don't express enthusiasm for a service, it's quite likely it might not get worked on. I, for one thing, would be interested in something like this. To be clear, I don't have anything which is currently *waiting* for this. Your interest is noted, thanks! -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r47zhwrg@qurzaw.varnish-software.com
Re: Debian services and Debian infrastructure
On Wed, Jan 22, 2014 at 11:07:49PM +0100, Tollef Fog Heen wrote: It's sgran who's been thinking about how to do this, but afaik he's seen close to zero interest from developers for it, so it's not happened yet. I don't think we need anything from the DPL as such, but if people are actually interested in something like this happening, saying so would be a good start. o/ I am currently working on http://ci.debian.net (WIP), to run autopkgtest (aka DEP-8) test suites. While developing on my own machine is completely fine, to actually try it out I need external resources even during development because of the demand in processing power: current with only ~200 packages having DEP-8 tests the longest run already took 14h to complete (in a single VM running test suites sequentially). It's currently running the test suites with schroot, but to make sure every test suite runs on a clean environment I will need to switch to using fresh VM's for each test suite. Also parallelizing the runs will be required to have timely results. The proof of concept is running on a Amazon EC2 VM from Debian's credits. I am a little ambivalent on this: on one hand, having this kind of resource available in a DSA-managed environment would have been useful. On the other hand, first prototyping it somewhere where we have free credits helps in knowing how much we will actually need from non-ephemeral, DSA-managed resources when the service gets to a production-ready state, so we might be saving DSA's most precious resource which is people's time. -- Antonio Terceiro terce...@debian.org signature.asc Description: Digital signature
Upcoming stable point release (7.4)
Hi, The next point release for wheezy (7.4) is scheduled for Saturday February 8th. Stable NEW will be frozen during the preceding weekend. As usual, base-files can be uploaded at any point before the freeze. Regards, Adam -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1390507736.6444.23.ca...@jacala.jungle.funky-badger.org
Upcoming oldstable point release (6.0.9)
Hi, The next point release for squeeze (6.0.9) is scheduled for Saturday February 15th. Stable NEW will be frozen during the preceding weekend. As usual, base-files can be uploaded at any point before the freeze. Regards, Adam -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1390507759.6444.24.ca...@jacala.jungle.funky-badger.org
State of the debian keyring
I have been asked to share this information.
Firstly, to view a report on your own key, substitute your fingerprint
in the following pipeline:
hkt export-pubkeys --keyring /usr/share/keyrings/debian-keyring.gpg \
4E46 9519 ED67 7734 268F BD95 8F7B F8FC 4A11 C97A | hokey lint
The following three reports were generated with debian-keyring
2013.12.13, hopenpgp-tools 0.4-1, jshon 20131010-3, and the
inefficient script attached. It represents incorrect handling of
revoked UIDs and user attributes, and possibly unknown bugs.
Judgments are based on this document[0] and are not generalized
per key.
The value `null` could mean OK. The term expiration passed
means that the UID or user attribute has expired. The report
format expresses this poorly, but the correlation of 1024-bit
to DSA keys is exactly 1:1 modulo a single 1024-bit RSA key
in debian-keyring.gpg. Subkeys are ignored as irrelevant for
this analysis.
[0] https://we.riseup.net/debian/openpgp-best-practices
(/usr/share/keyrings/debian-keyring.gpg)
Total keys: 996
Key versions:
996 4
Primary key pubkey algorithms:
623 DSA
373 RSA
Primary key pubkey sizes:
624 1024
27 2048
2 3072
340 4096
2 8192
1 10240
Total number of UIDs + UAts: 4394
Hash algorithm used for most recent self-sig:
1 RIPEMD160
3188 SHA1
1041 SHA256
1 SHA384
163 SHA512
Judgment on preferred hash algorithms:
1776 null
2618 weak hash with higher preference
Judgment on expiration times:
53 expiration passed
111 expiration too far in future
3887 no expiration set
343 null
(/usr/share/keyrings/debian-maintainers.gpg)
Total keys: 200
Key versions:
200 4
Primary key pubkey algorithms:
54 DSA
146 RSA
Primary key pubkey sizes:
54 1024
1 1280
13 2048
1 3072
130 4096
1 8192
Total number of UIDs + UAts: 593
Hash algorithm used for most recent self-sig:
294 SHA1
234 SHA256
65 SHA512
Judgment on preferred hash algorithms:
416 null
177 weak hash with higher preference
Judgment on expiration times:
9 expiration passed
18 expiration too far in future
485 no expiration set
81 null
(/usr/share/keyrings/debian-nonupload.gpg)
Total keys: 9
Key versions:
9 4
Primary key pubkey algorithms:
9 RSA
Primary key pubkey sizes:
1 2048
8 4096
Total number of UIDs + UAts: 25
Hash algorithm used for most recent self-sig:
7 SHA1
16 SHA256
2 SHA512
Judgment on preferred hash algorithms:
24 null
1 weak hash with higher preference
Judgment on expiration times:
14 no expiration set
11 null
#!/bin/zsh
infile=${1:-/usr/share/keyrings/debian-keyring.gpg}
tempfile=$(mktemp)
trap 'rm ${tempfile}' EXIT
hokey lint --output-format JSON ${infile} ${tempfile}
print -n Total keys:
jshon -a -e keyFingerprint ${tempfile} | wc -l
print Key versions:
jshon -a -e keyVer -e val ${tempfile} | sort | uniq -c
print Primary key pubkey algorithms:
jshon -a -e keyAlgorithmAndSize -e pubkeyalgo -e val ${tempfile} | sort | uniq
-c
print Primary key pubkey sizes:
jshon -a -e keyAlgorithmAndSize -e pubkeysize -e val ${tempfile} | sort -n |
uniq -c
print -n Total number of UIDs + UAts:
jshon -a -e keyUIDsAndUAts -k ${tempfile} | wc -l
print Hash algorithm used for most recent self-sig:
jshon -a -e keyUIDsAndUAts -a -e uidSelfSigHashAlgorithms -a -e val
${tempfile} | sort | uniq -c
print Judgment on preferred hash algorithms:
jshon -a -e keyUIDsAndUAts -a -e uidPreferredHashAlgorithms -a -e explanation
${tempfile} | sort | uniq -c
print Judgment on expiration times:
jshon -a -e keyUIDsAndUAts -a -e uidKeyExpirationTimes -a -e explanation
${tempfile} | sort | uniq -c
