Re: Salsa as authentication provider for Debian
On Sun, Apr 12, 2020 at 08:21:49AM +0300, Andrei POPESCU wrote: > On Sb, 11 apr 20, 19:27:53, Julien Cristau wrote: > > On Sat, Apr 11, 2020 at 10:04:55AM +0300, Andrei POPESCU wrote: > > > > > > I must be missing something so I'm asking: what is the *benefit* of > > > avoiding collisions with Debian accounts? > > > > > f...@salsa.debian.org and f...@debian.org both existing and referring to > > different people risks causing confusion. I'd like to understand why > > we're going that way. > > If I understand correctly, then, using the -guest suffix would allow for > foo-gu...@salsa.debian.org and f...@debian.org both existing and > referring to different people. > > In my opinion this still doesn't significantly reduce the risk of > confusion while also being quite unfriendly should the foo-guest user > ever wish to become a Debian Member. This is why having a central approach to account creation, rather than distributed, is worth considering. I'm in favour of usernames not changing because one's role changes but that does not mean I'm favour of divergent namespaces. -- Luca Filipozzi signature.asc Description: PGP signature
too many acronyms [was: Testing Discourse for Debian]
On Fri, Apr 10, 2020 at 03:26:16PM -0400, rhkra...@gmail.com wrote: > On Friday, April 10, 2020 02:59:59 PM Neil McGovern wrote: > > For a little while, I've been keen to see how we can improve our > > communication methods, both to make it more accessible to newcomers > > Hmm, from the peanut gallery, if you really want things accessible to > newcomers, it would be nice if fewer abbreviations were used -- things like > DPL, CP, SP, ... > > I'm not particularly talking to you, but more to the participants in the > "Salsa as authentication provider for Debian" thread. Good point. There's a mix of Debian and Identity acronyms in that thread. Here's a couple of links to help, I hope: https://www.identropy.com/blog/iam-blog/bid/77844/commonly-used-acronyms-in-identity-and-access-management https://wiki.debian.org/Glossary -- Luca Filipozzi
Re: Salsa as authentication provider for Debian
On Fri, Apr 10, 2020 at 02:08:01PM -0400, Sam Hartman wrote: > >>>>> "Russ" == Russ Allbery writes: > > Russ> Luca Filipozzi writes: > >> On Fri, Apr 10, 2020 at 11:48:22AM -0400, Sam Hartman wrote: > > >>> * Note that if you want to you can host accounts in gitlab and > >>> have keycloak act as an OIDC consumer for gitlab. So, if you > >>> decide you like Gitlab as an IDP but find you need Keycloak's > >>> transformations, you can have people login to Keycloak using > >>> their Gitlab accounts. > > >> I reiterate my point that an SP being an IdP. I don't view using > >> Debian's Gitlab as an IdP to be a prudent move. > > Russ> I don't understand this objection. The relying party and the > Russ> identity provider are certainly different components with > Russ> different functions, but that doesn't imply that they can't be > Russ> combined in the same software suite. There's quite a lot of > Russ> shared code between an SP and an IdP, so in some sense that's > Russ> easier than maintaining them as entirely separate projects. > > I echo Russ's thoughts exactly. > Russ and I both have a long history in the SSO world, and I think that > if two people who have history say "we don't see the objection," it's > a good idea to explore your objection in significantly more detail than > simply asserting it. I'm not saying that gitlab's IdP implementation is poor (another thread: is discussing it's quality, however). The fact that gitlab shares code between SP and IdP is not my concern. Let me be more precise: I'm talking about the service itself and not about the SP. I think that our services -- such as SCM, CI/CD, Wiki, RT, etc. -- should evolve indepdently from the SSO infrastructure. One could argue that RT has a user database thatcould be used as authenticaion service if exposed correctly. Or the Wiki. Some organizations use their mailing list system (sympa, in particular) as their group management solution. None of this coupling between user management, group management, authentication services and a specific service strikes me as prudent. My observation is strictly related to the coupling of these things. If I'm the only one with this concern, so be it. -- Luca Filipozzi
Re: Salsa as authentication provider for Debian
On Fri, Apr 10, 2020 at 12:06:42PM +0200, Bastian Blank wrote: > On Wed, Apr 08, 2020 at 03:18:58PM +0000, Luca Filipozzi wrote: > > > - Salsa, how should it work together. > > Gitlab can use OIDC as an OmniAuth provider. > > And here the problems begin. > > Sure, just using it as OmniAuth provider works. But this only provides > authentication. > > But, as Sam correctly mentioned, as all others ignored it: we need > user life cytle. And just using OmniAith does not provide any life > cycle control. > > > > - Who is willing to maintain this long-term > > I'm not committing DSA to this but I'm encouraged by their interest in a > > demo. > > There are at least three people on the thread who are familiary with > > SAML/OIDC who are interested in supporting this service. > > You are opting in to maintain three monsters: > - Java > - Wildfly > - Keycloak Java is already maintained by a team. I'm not proposing to maintain wildfly independently from keycloak. I appreciate that there's a 'vendor library' discussion here. > > > What isn't so great > > > - no particular good admin interface (there are 40+ settings for each > > > OIDC client alone) > > > > Nearly all of those settings are auto-populated by exchanging metadata. > > In SAML, the SP and the IdP exchange XML documents containing the > > metadata. Tedious but works. In OIDC, the SPI and the IdP point to each > > other's 'well-known' configuration URLs to pull in the metadata. The > > OIDC folks learned from SAML. > > No, Keycloak is running as OIDC server in this case, so it _provides_ > all the settings via the metadata discovery mechanism. > > It's just that the existence of most of those options negates the > possibility to allow a random user to use it safely. There are two things that I need to think about here: (1) how to allow users to add SPs (2) how hard is it to add SPs > > > - it can have forms without a required field, which can't be saved at > > > all. > > Not sure what you're describing, here. > > Just random bugs. > > - Enable "email as username" > - Try to add a user by admin interface > > > > - requires Java 8, which is not supported on Debian Buster > > > > This isn't true. I'm running keycloak in a demo for work using > > openjdk-11-jre-headless. Their documentation would do well to say > > Java 8 or later. > > The latest installation doc is pretty specific: > > https://www.keycloak.org/docs/latest/server_installation/#system-requirements Maybe I'll file a documentation bug seeking a correction. Redhat have worked hard to keep wildfly operable on the latest GA java version. In other words, keycloak9 on wildfly18 on java11. I expect that kecloak10 on wildfly19 will be released soon: wildfly19 was released a few weeks ago. Their support for latest GA java will cease, temporarily, with java14 because they are still digesting the impact of package removals compared to java11. -- Luca Filipozzi
Re: Salsa as authentication provider for Debian
On Fri, Apr 10, 2020 at 11:48:22AM -0400, Sam Hartman wrote: > * I was right. Gitlab can work as an identity broker. They > generally have people use keycloak to log into gitlab. However, there > is one common app where it was easier to set up that app to consume > gitlab than keycloak so they did. My point is that an SP shouldn't be an IdP nor an IdB. We should separate these concerns. > * This organization does not use keycloak to host accounts. That is, > all the accounts are stored something else. There are no locally > created keycloak accounts. When operating as an IdB, there's always a local 'account' represenatation in keycloak's DB. It contains the record that ties a user to IdPs, and exposes a single user representation to to service providers. A user might start their journey using a social identity and then switch to a Debian identity. Debian LDAP | | Debian IdP --+ +-- Social IdP2 | | IdB - Service Providers | | Social IdP1 --+ +-- Social IdP3 (Sam: Above is an ASCII art diagram showing that Debian IdP and Social IdPs would be tied into the IdB.) That's different than enabling "local account", which we could leave off. That would mean people would need a social identity to start with. That said, keycloak does have a local user onboarding flow. > * On the call, our suspicion is that gitlab is going to do a better job > of account lifecycle management than keycloak, but again, the > organization in question has not tried that with keycloak. It seems > that having local accounts in Keycloak is not one of its most polished > features. But again, this is a guess without explicit experience. I'd say that a proof of concept is needed. > * Note that if you want to you can host accounts in gitlab and have > keycloak act as an OIDC consumer for gitlab. So, if you decide you > like Gitlab as an IDP but find you need Keycloak's transformations, > you can have people login to Keycloak using their Gitlab accounts. I reiterate my point that an SP being an IdP. I don't view using Debian's Gitlab as an IdP to be a prudent move. -- Luca Filipozzi
Re: Salsa as authentication provider for Debian
On Wed, Apr 08, 2020 at 03:18:39PM +0200, Enrico Zini wrote: > On Wed, Apr 08, 2020 at 08:25:06PM +0800, Shengjing Zhu wrote: > > > > I understand you want to recognize DDs from other contributors, but why? > > > Does it help you with permissions, does it help understand who someone > > > is, or is it a habit that has been there since Alioth? > > > > For me, it's easier to trust a DD than a non-DD, so I'll grant a role > > with higher permission if they request to join a team/project. > > I think this has ups and downs. Another view point: I don't think that one's username should change as one's role(s) with the organization changes. If we could avoid that... -- Luca Filipozzi
Re: Salsa as authentication provider for Debian
On Wed, Apr 08, 2020 at 06:23:29AM -0400, Sam Hartman wrote: > Debian has two account life cycle work flows that we're reasonably happy > with (or at least not proposing to change now). > > The first is the account life cycle for developers. DAM sends a signed > ticket to keyring-maint and DSA, and accounts get created or locked. > Developers send signed tickets to some combination of folks to deal with > name changes. > > There's another flow. Contributors interact with DSA in some process I > do not fully understand to get guest accounts on porter boxes etc. The third flow being 'guests' in Debian LDAP. > These account life cycle flows are too heavy-weight for several tasks > that we find: > > * someone wants an account on salsa for hosting projects or interacting > with projects there. > > * Someone wants to manage their contributors.debian.org info > > * Someone wants to enter the nm process. (This will eventually get to > the heavy weight account life cycle, but we want starting the > application to involve zero signed RT tickets) > > * People want to run services that consume Debian community accounts. > > So, it's not just that we need an SSO provider. > we need a light weight account life cycle system that will fit into our > SSO strategy. With keycloak (or LLNG) set up as as a broker, then user account self-creation is possible (caveat waldi's comments about attrs and groups which requires more investigation). > It also needs to eventually interact with nm, which will allow it to > work with the existing account life cycle flow for developer accounts. > But given Enrico's interest, I think it's safe to say that nm > interactions are being considered. With keycloak, when a user becomes a DD, we add an LDAP account and ask the user to merge on next login via keycloak workflows or we use keycloak APIs to merge for them. > so, a lot of people are jumping up and down talking about particular SSO > strategies focusing on the SSO aspects of those strategies. No one is jumping, thank you. > Where as what is the most important gaps for our project surround the > account life cycle stuff. > > And for all its faults, Gitlab has a very easy story for this. > > You can maintain an account in gitlab with a username and password. > > In the long run you can also front gitlab with something else provided > that you have a something else that does account lifecycle > management. > > As a reminder, no one is talking about having DSA trust gitlab to > control access to the archive or Debian machines. I think we all > cringe thinking about that. Well, given this DPL statement, shall I continue answering other emails in this thread or no? That is the question now. -- Luca Filipozzi
Re: Salsa as authentication provider for Debian
On Wed, Apr 08, 2020 at 05:28:37PM +0200, Enrico Zini wrote: > On Wed, Apr 08, 2020 at 03:00:31PM +0000, Luca Filipozzi wrote: > > > > Question: is there something in the proposed Salsa plan that somehow > > > blocks experimenting with, introducing, or migrating to Keycloak in the > > > future? > > > > The further we go down one path, the harder, in my opinion, to change > > later. > > I think we're not really going "down one path": we're trying to dig > ourselves "out of one pit". > > I'll have to repeat the question: is there something specific in the > proposed Salsa plan, that somehow blocks experimenting with, > introducing, or migrating to Keycloak or some other solution in the > future? I think introduction of the broker is the compelling use case. I appreciate that you may not view that as sufficient compelling. Additionally, I'd prefer keeping SPs separate from IdPs, have them speak to each other using standard protocols, etc. I don't view making Gitlab an IdP as appropriate. > From what I can see so far, we're starting a migration to OIDC, removing > one of 3 user databases, adopting more standards, and doing some general > cleanup along the way, which makes me think Salsa could be considered an > iterative step towards a migration to anything else. Very good outcomes, to be sure. > If you're instead generally expressing a fear that once we migrate to > Salsa, we'll be in a local optimum that is going to be considered good > enough to be worth bothering migrating to anything else, then I would > argue that the problem wouldn't be having moved to Salsa as an OIDC > provider, and rather that the next step that is proposed wouldn't be > bringing enough compelling advantages to the problem at hand. Indeed, a local optimum is worrisome. -- Luca Filipozzi
Re: Salsa as authentication provider for Debian
reminder: I'm replying linearly (in this case, at the end of a chain of email) and from what I know (keycloak, SAML and OIDC). On Tue, Apr 07, 2020 at 04:08:37PM +0200, Xavier wrote: > Le 07/04/2020 à 16:02, Enrico Zini a écrit : > > On Tue, Apr 07, 2020 at 03:28:07PM +0200, Xavier wrote: > > > >> With a SSO, I don't think it's a good thing to have a protected app as > >> user database (even if it's possible). Then migration consists to > >> extract gitlab accounts and push them in LDAP (2 branches, one for DD, > >> one for guests) > > > > Ok, please help me to see where that would be an issue. > > It's not an issue. With a SSO we shall probably change this: salsa > accounts will be created on-the-fly using federation mechanism, then > there is only one user database (LDAP with 2 branches) The Debian LDAP is atypical in a variety of ways, it's true. Like LLNG, Keycloak use mappers to pull / transform as necessary. -- Luca Filipozzi
Re: Salsa as authentication provider for Debian
reminder: I'm replying linearly and from what I know (keycloak, SAML and OIDC). On Tue, Apr 07, 2020 at 12:20:40PM +0200, Xavier wrote: > Le 05/04/2020 à 20:46, Bastian Blank a écrit : > I can help if you want to use lemondap-ng (LLNG: > https://lemonldap-ng.org https://tracker.debian.org/pkg/lemonldap-ng) Cool. > This requires to change all services. Using a SSO is easier here: > gatekeeper (KeyCloack) or handler (LLNG) permits to protect a web app > without having to change to many things. LLNG handlers are directly > included in Apache/Nginx configuration and provides HTTP-headers to the > web app. Or Apache modules like mod-auth-openidc (OIDC) or mod-auth-mellon (SAML). > Other way, LLNG is able to be a proxy between OAuth (OpenID-Connect) and > any other SSO-language (CAS, SAML, OpenID-2) or handlers. The portal > then becomes transparent Keycloak, as a broker, is similar. Service provider can be using one protocol and the identity provider another. > It's easy to integrate GitLab in SSO using SAML (or OIDC). It is perhaps > more safe to manage users elsewhere (custom app) and make GitLab a slave > of SSO system. LLNG provides a plugin engine for that. Gitlab can use OIDC for OmniAuth, so it can authenticate against any OIDC-compliant IdP, LLNG and Keycloak included. > NB: KeyCloak is free but this needs to stay in last version, else you > need a RedHat-SSO support. LLNG is totally free, written in Perl and JS; > and Debian has a lot of Perl-Gurus ;-). Redhat has the distinction (thankfully) of not following a 'freemium' model (at least for Directory389 and Keycloak). The features available in RedHat SSO and Keycloak are identical. Redhat SSO lags behind Keycloak but may include fixes not yet ported to Keycloak. Keycloak is also totally free and, yes, is written in Java. > I can give some accounts to demo platform: https://auth.openid.club/ > [dev platform, so sometime broken...] or install an instance in a Debian > machine if you want to try it. Please work with Michael Lustfield (IRC MTecknology) as he is also interested in setting upa Debian-specific instance of LLNG. > Resume of proposition: > * all users managed by SSO; Agree! > * self-registration authorized with "-guest" >in a distinct LDAP branch More thought required but don't disagree. > * GitLab becomes a slave of SSO using SAML (or OIDC) Agree! > * other applications are protected by handlers/GateKeepers. If LLNG is >chosen, just to add few lines in Nginx configuration Agree and/or mod-auth-openidc/mod-auth-lemon, etc. > * new applications can be protected using handlers, SAML, CAS, OIDC,... Agree but with order of preference being OIDC, SAML and... way over there, almost too distant to see... CAS. > Very helpful response! -- Luca Filipozzi
Re: Salsa as authentication provider for Debian
reminder: I'm answering these linearly and i'm speaking from what I know
(keycloak) not what I don't (LLNG). I expect LLNG is generally similar.
On Tue, Apr 07, 2020 at 08:53:47AM +0200, Bastian Blank wrote:
> On Mon, Apr 06, 2020 at 04:09:38PM +0000, Luca Filipozzi wrote:
> > That said, please consider an approach that would see keycloak used as
> > an idenitity broker, allowing external users to create accounts using
> > social identities that are then promoted to full Debian identities (in
> > LDAP) if they complete the onboarding process.
>
> You are proposing a different idea, however you are not yet proposing a
> project with actionable items on it. If you think this is worthwhile,
> please provide at least the following things:
Responding to "here's an idea: try keycloak" with "publish a full plan"
creates a mountain when we're just at the foothills. I appreciate that,
from your perspective, you've been at this for a year and are
frustrated. I'll respond briefly to these below but, if we want a
fulsome plan, we should create a wiki page with the use cases and
evaluate things against the use cases a bit more.
> - Workflows, esp non-DD to DD and vice versa.
non-DDs can create accounts locally in keycloak and/or tie them to
social identity providers ("let them use existing credentials"). If they
becomee DDs, later, we add them to LDAP and cause them to 'merge' their
accounts on next login (or we use keycloak's API).
> - Self service, e.g. user signup, how do users add OIDC clients, how add
User signup is described above. Individual services could accept all
users or could require specific role assignment. Service owners would
then need to decide on role assignment mechanism.
I've not tried empowering non-admin users to add service providers
to a keycloak IdP. I don't doubt it's possible, just have to try.
> groups/roles to OIDC info.
Yes, keycloak has powerful mapping capability to allow groups/roles to
be exposed as assertions to service providers.
> - Salsa, how should it work together.
Gitlab can use OIDC as an OmniAuth provider.
> - Additional features
> - Who is willing to maintain this long-term
I'm not committing DSA to this but I'm encouraged by their interest in a
demo.
There are at least three people on the thread who are familiary with
SAML/OIDC who are interested in supporting this service.
> - Exit strategy
I'm still at ideation.
> Anyway, I took a quick look into Keycloak.
>
> What I find particular interesting is:
> - they use UUID for user identification
internally, yes. what is passed to a service provider as an identity
assertion can be configured through mapping rules on an SP-by-SP basis
> - users and groups can have arbitrary attributes attached to them,
> however they are not self service
> - it is a complete authorization solution
>
> What isn't so great
> - no particular good admin interface (there are 40+ settings for each
> OIDC client alone)
Nearly all of those settings are auto-populated by exchanging metadata.
In SAML, the SP and the IdP exchange XML documents containing the
metadata. Tedious but works. In OIDC, the SPI and the IdP point to each
other's 'well-known' configuration URLs to pull in the metadata. The
OIDC folks learned from SAML.
> - it can have forms without a required field, which can't be saved at
> all.
Not sure what you're describing, here.
> - jboss. Who considers itself capable of running public jboss
> applications safely and securely?
Yes, there's a general lack of interest in Java and JBoss in our
community.
> Showstopper
> - no self service for group or even OIDC clients
More investigation required, frankly.
> - no U2F (okay, GitLab also still needs to make the step to webauthn)
> - requires Java 8, which is not supported on Debian Buster
This isn't true. I'm running keycloak in a demo for work using
openjdk-11-jre-headless. Their documentation would do well to say Java 8 or
later.
> I was not able to see the killer feature of this setup or at least one
> feature that we must have.
I think the 'killer feature' is independent of Keycloak. It's the
introduction of an identity broker that offers a single place for
service providers to integrate, offers social-to-identity for users,
etc.
--
Luca Filipozzi
Re: Salsa as authentication provider for Debian
I'm working through the responses linearly, so... On Tue, Apr 07, 2020 at 09:28:34AM +0200, Enrico Zini wrote: > On Mon, Apr 06, 2020 at 07:07:26PM +0000, Luca Filipozzi wrote: > > > > I don't know keycloak: what are the maintenance costs, and what would be > > > the benefits over time? > > > > > > Right now, with the proposal waldi just posted, we have very little to > > > no added maintenance cost, possibly negative maintenance cost once we > > > take sso.debian.org and the current handcrafted salsa subscription thing > > > offline. The amount of code deployed compared to the status quo would go > > > *down*. The user interface and user experience for the lot would be good > > > and well known. Gitlab's codebase, while large and complex, is widely > > > deployed, and we already have know-how about it in Debian. Having read the response relating to an audit of gitlab source code, I would question whether gitlab is 'saft'. That said, we'd want similar attestations for LLNG or keycloak. Keycloak has been selected by a number of governments / unis / etc. That's not to say that they did code reviews; it is to say that it is receiving some adoption (which I think will grow). I know more about keycloak than LLNG, so I'll restrict my responses to Keycloak, SAML and OIDC (OpenID Connect). > > Having just joined this conversation, the above is an argument that is > > difficult to refute: one can always argue that 'one in the hand is > > better than one in the bush'. > > Yes :/ I think that's more or less where we are now, unfortunately, > after a year or more failing to find people to deploy and maintain > alternatives. I think people are stepping forward, albeit slowly. > On one hand, client certificate handling in browsers gets worse over > time, and the current sso solution is effectively running on people > collecting all sorts of workaround instructions in the excellent wiki > page at https://wiki.debian.org/DebianSingleSignOn I suggest that we move from client certificate-based authentication to SAML- or OIDC-based authentication. > On the other hand, signing in for non-DDs is a major hurdle that takes > literally weeks, when one can find out how to do it at all. We DDs care > little about that, it's Not Our Problem. That barrier makes joining > nm.debian.org to become a DD a challenge in itself. Other things like > managing one's own information on contributors.debian.org are just not > worth the challenge, and I'm planning to take contributors.d.o offline > soon, because I/we can't, ethically and legally, publish people's > information without giving those people a reasonable chance to control > it. With keycloak, we could: * allow people to create accounts locally in keycloak, and//or * allow people to create accounts tied to other identity providers (Gmail, etc.) This is the 'social-to-identity' concept where an organization wishes to make onboarding of new users as friendly as possible (let them use their existing credentials). If, later, they become a customer (i.e., Debian Developer), then you promote their account from 'social' to 'internal'). > > My DSA colleagues asked for demo and I'm building that up, currently. I > > view this as a positive but not definitive step in the maintenance > > questions. > > > > I appreciate that the idea of using keycloak as an IdB requires everyone > > to shift perspective. > > > > Let me know if you have appetite (or not*) to discuss the above. > > Personally I'm interested in anything that works and that I can have a > very good confidence that somebody will maintain over time. > > I care about maintenance and sustainability more than about anything > else, because I'm the one who's been forced to set up and maintain SSO > in Debian mostly alone for 8 years, because everybody else walked away > from it and I could not. > > OIDC supports various authentication sources, and the Salsa plan > decouples OIDC from LDAP allowing them to evolve independently, removes > custom nonstandard components, and includes the option of migrating away > to something else in the future. In my understanding it enables > experimentation with other systems rather than blocking it. > > Question: is there something in the proposed Salsa plan that somehow > blocks experimenting with, introducing, or migrating to Keycloak in the > future? The further we go down one path, the harder, in my opinion, to change later. -- Luca Filipozzi
Re: Salsa as authentication provider for Debian
On Mon, Apr 06, 2020 at 08:38:59PM +0200, Enrico Zini wrote: > On Mon, Apr 06, 2020 at 04:09:38PM +0000, Luca Filipozzi wrote: > > > That said, please consider an approach that would see keycloak used as > > an idenitity broker, allowing external users to create accounts using > > social identities that are then promoted to full Debian identities (in > > LDAP) if they complete the onboarding process. Could be used as > > replacement for debsso, could be used for wiki, could be used for > > debconf, could be used for salsa. > > I don't know keycloak: what are the maintenance costs, and what would be > the benefits over time? > > Right now, with the proposal waldi just posted, we have very little to > no added maintenance cost, possibly negative maintenance cost once we > take sso.debian.org and the current handcrafted salsa subscription thing > offline. The amount of code deployed compared to the status quo would go > *down*. The user interface and user experience for the lot would be good > and well known. Gitlab's codebase, while large and complex, is widely > deployed, and we already have know-how about it in Debian. Having just joined this conversation, the above is an argument that is difficult to refute: one can always argue that 'one in the hand is better than one in the bush'. > I would not want to see a workable proposal that we could implement over > the next two weeks and that we have the resources to maintain long-term, > blocked by something that risks getting us stuck with sso.d.o for > another bunch of years until we get it right, and possibly ending up > being maintained long term by a team with a dwindling bandwidth and bus > factor. Again, I'm just joining this conversation now. Keycloak is a RedHat-sponsored Java-based open-source project that provides a standards-based (SAML and OpenID) Identity Provider (IdP). It can also operate as an Identity Brokder (IdB). As an IdP, it can use an internal data store for users (database) or an external one (LDAP). It has a variety of workflows for user onboarding, user managed access, etc. As an IdB, it can be configured to allow 'social-to-identity' workflows so that users may begin their identity experience using their existing social identies (Gmail, Twitter, etc.). This is in addition to the users from the above IdP for Debian Developers. Service operators (websites, etc.) could then elect to accept all users or to require a role assignment / group membership to grant access to the service. Finally, should a user have started with a social identity but have successfully completed the Applicant process, then there are workflows that would allow users to merge their identities. My DSA colleagues asked for demo and I'm building that up, currently. I view this as a positive but not definitive step in the maintenance questions. I appreciate that the idea of using keycloak as an IdB requires everyone to shift perspective. Let me know if you have appetite (or not*) to discuss the above. Thanks, Luca * If not, then I'll stop advocating for this approach. There's the potential for a heated conversation, here, and I'm not up for that. -- Luca Filipozzi
Re: Salsa as authentication provider for Debian
On Sun, Apr 05, 2020 at 08:46:10PM +0200, Bastian Blank wrote: > We did not receive a response from DSA to date. We only got some personal > remarks from jcristau and weasel on IRC. They don't want to handle Salsa > differently and store information. Also they declared worry about user name > conflicts. > > We did some changes to remedy those, so we scrapped the changes we had asked > DSA to do and will check for name conflicts in nm.debian.org before sending > user creation requests to DSA. I think the above mischaracterizes DSA's response and opinion: specifically, there was an engagement with you in #debian-admin on or about April 3rd in response to this topic specifically. That said, please consider an approach that would see keycloak used as an idenitity broker, allowing external users to create accounts using social identities that are then promoted to full Debian identities (in LDAP) if they complete the onboarding process. Could be used as replacement for debsso, could be used for wiki, could be used for debconf, could be used for salsa. Thanks, Luca -- Luca Filipozzi
Re: Realizing Good Ideas with Debian Money
On Sat, Jun 01, 2019 at 12:29:04PM +0200, Tollef Fog Heen wrote: > ]] Russ Allbery > > Particularly now that my free time is rarer and more precious to me, > > doing unpaid work for an organization that also has paid staff is > > hugely demotivating. It's entirely plausible that paying for > > resources would mean that Debian would end up with *less* resources > > than we have now, if other volunteers feel the same way. > > Well said, and I feel the same way. Same same. -- Luca Filipozzi
Re: Realizing Good Ideas with Debian Money
On Fri, May 31, 2019 at 10:57:51PM +, Holger Levsen wrote: > On Fri, May 31, 2019 at 10:56:16PM +0000, Luca Filipozzi wrote: > > > For me this implies that Debian should aim at having at least US$500k > > > reserves, to be prepared if there is no large donation coming for a > > > future refresh. > > Plus another $300k in reserves for DebConf in case those donations don't > > come through. > > we never had that. we do have reserves at SPI; it's why SPI feels comfortable signing hotel and venue contracts against "commited donations" > how did we manage to survive those last >25y? because, thankfully, the donations do come through for DebConf and because, historically, HPE and Bytemark have donated a lot of hardware (thanks HPE and Bdale!), no ... but this is no longer the case -- Luca Filipozzi
Re: Realizing Good Ideas with Debian Money
On Sat, Jun 01, 2019 at 01:50:25AM +0300, Adrian Bunk wrote: > On Fri, May 31, 2019 at 09:04:24PM +0000, Luca Filipozzi wrote: > >... > > When we last crunched the numbers, maintaining a 5y refresh (to stay in > > warranty, etc.) would require $75k-100k/yr. We've avoided that level of > > annual expenditure because we are keeping hardware longer than 5y and > > we've had amazing hardware [donations][1]. > >... > > For me this implies that Debian should aim at having at least US$500k > reserves, to be prepared if there is no large donation coming for a > future refresh. Plus another $300k in reserves for DebConf in case those donations don't come through. -- Luca Filipozzi
Re: RFA: rtc.debian.org
On Tue, Apr 30, 2019 at 01:47:25PM -0400, Sam Hartman wrote: > Is the xmpp server part of rtc.debian.org or another service? Part of the same service. -- Luca Filipozzi
Re: Debian contributor Register of Interests
On Tue, May 09, 2017 at 01:09:28PM +0100, Ian Jackson wrote:
> Jonathan Dowland <j...@debian.org> wrote:
> > However in the interests of transparency I feel that a voluntary,
> > opt-in "Register of Interests" is a good idea for the project. I feel
> > that such a list (populated) would demonstrate the transparency and
> > openness that are part of our project's values.
>
> I think this is a good idea.
AOL
> >> This is a voluntary, opt-in register of Debian contributor's "Interests"
> >> (such as: employer).
>
> It would be a good idea to make an annex, giving a list of kinds of
> "interest" that do not need to be mentioned; and ones that should be
> mentioned.
>
> Things that are _not_ interests worthy of disclosure:
>
> * Holding positions of responsibility within the Debian project,
> or a Debian Trusted Organisation
Arguably, holding a position of responsibility within the Debian project or a
Debian Trusted Organization is what might trigger the completion of a CoI form.
> * Involvement with political parties (even ones focusing on
> technology or information rights)
>
> * Using Debian or one of its derivatives, on one's personal
> systems
>
> * Holding positions of responsibility in Free Software projects,
> other than positions of financial responsibility for projects with
> assets or annual income of more than Eur1,000.
>
> * Mere membership of charities, pressure groups, industry
> associations, etc.
>
> Things that _are_ interests worthy of disclosure:
>
> * Being paid to work on Debian
>
> * Being paid to work on hardware that Debian runs on or might run on
>
> * Being in a position of influence or authority regarding technology
> purchasing decisions. Exceptions: your own personal purchasing
> and that of your household and your friends; Debian and Debian's
> TOs.; spends of less than Eur1,000 per year.
>
> * Holding a formal position of influence or authority in charities,
> pressure groups or industry associations which relate to software
> or computing hardware, information rights, or state-granted
> information monopolies ("intellectual property").
>
> I would like to settle the boundaries before we start populating the
> list.
Fully agree.
> >> || '''User''' || '''Interest''' || '''From''' || '''Until''' ||
> >> || JonDowland || Red Hat || 2015 || - ||
>
> The list should have a date at which the user's entry was last
> updated and signed off by them as complete.
Just as delegations are meant to be refreshed annually, I wonder whether CoIs
should be refreshed annually.
Also, perhaps the CoI 'form' should be an email template that submitters
complete and mail somewhere (GPG-signed). This 'somewhere' could be presented
in a list on some webpage or other. I'm not solutioning, here. I'm questioning
whether we want the non-repudiation that a GPG-signed email provides (or
similar mechanism).
Thanks,
Luca
--
Luca Filipozzi
http://www.crowdrise.com/SupportDebian
Re: If Debian support OS certification?
On Fri, May 05, 2017 at 10:40:10PM +0100, Ben Hutchings wrote: > On Fri, 2017-05-05 at 16:54 +0200, Thomas Goirand wrote: > > On 05/02/2017 02:35 AM, Paul Wise wrote: > > > With my DSA hat on, we don't like being guinea pigs for development > > > boards and pre-release hardware. This kind of hardware tends to be > > > unreliable and require too much hand-holding. That said, we definitely > > > welcome hardware sponsorship and partners. > > > > Absolutely. However, you may know that commercial distros are making > > their certification program a non-free (as in: you must pay your beer) > > thing. I do believe it'd be a fair way to get free (as in free beer) > > hardware for the DSA team. It's up to us to define the terms. > > Free as in free kittens? I'm not interested in hardware as payment for certification. It's too open to abuse. Charge a fee for certification testing; use the funds to buy hardware. -- Luca Filipozzi http://www.crowdrise.com/SupportDebian
Re: If Debian support OS certification?
On Tue, May 02, 2017 at 08:35:07AM +0800, Paul Wise wrote: > On Tue, May 2, 2017 at 5:15 AM, Thomas Goirand wrote: > > > While it is nice to answer the way you did, here, Debian is missing yet > > another opportunity that other commercial distro would not. Maybe we > > should have a BoF at debconf Montreal about this. > > Please do register a BoF, I'd be happy to attend if I can. Me, also. > > Quanta is a company shipping servers. If I'm not mistaking, they're > > located in Shanghai. One thing they used to do (and probably continue to > > do) is building servers matching open specifications from the "open > > compute" project. That really appeals to Debian moral standards, IMO. > > Thanks for the info. > > > What they are interested about, is having *us*, Debian, to certify that > > their hardware work on our system, so that their customer trust they can > > buy it to run Debian. It'd be a bit weird if they were certifying > > themselves. > > I think that Debian members/contributors do not and should not hold a > monopoly on verifying that Debian works on a particular piece of > hardware. > > I think a better approach would be to produce a Debian Live image that > on boot checks as much of the hardware as possible automatically and > lists a checklist for verifying the rest of the hardware works. Anyone > could run the image and the resulting report could be uploaded to > hardware.d.o, where it would be displayed publicly and count as a > "certification". This way users can trust Debian to run on the > hardware and there is no monopoly on certification. ISTR Ubuntu's > certification stuff works similarly except that only Ubuntu can give > the certification mark, probably in exchange for money. > > In any case, hardware vendors are in a much better position to be able > to certify that Debian runs on their hardware than we are. They know > exactly what functionality should be present and have access to get > more hardware in case running Debian bricks their devices. Wearing my DSA hat: fully agree. > > Now one idea: one way we could provide the certification would be asking > > for hardware sponsorship. This way, we (ie: the DSA team) would get > > "free" hardware, in exchange for a certification. Obviously, we'd need > > to discuss this with the DSA. > > With my DSA hat on, we don't like being guinea pigs for development > boards and pre-release hardware. This kind of hardware tends to be > unreliable and require too much hand-holding. That said, we definitely > welcome hardware sponsorship and partners. Wearing my DSA hat: fully agree. So tired of flakey hardware. Wearing my Partners hat: what value a certification that was 'bought' by donating hardware (or a variable amount of funding) to Debian. I'd prefer a declared fee structure for the service, for transparency. That said, I'd far prefer Paul's suggestion of a Live CD. > > Then we'd need a kind of "Debian certified hardware" logo that we would > > agree the certified company use for some hardware. This would need SPI > > approval, since that's the entity owning the rights for the Debian logo. > > I expect we can probably get a logo created by updating this: > > https://wiki.debian.org/DebianArt/RequestArtwork > > Often it takes some promotion for the right people to notice though. -- Luca Filipozzi http://www.crowdrise.com/SupportDebian
Re: producing, distributing, storing Debian t-shirts
On Sun, Apr 30, 2017 at 02:18:11PM +0200, Sebastiaan Couwenberg wrote: > On 04/30/2017 01:53 PM, Daniel Pocock wrote: > > - would it be reasonable for 1% - 2% of Debian's reserves to be tied up > > in slow moving inventory items like t-shirts that take up to a year to > > fully turnover? As the reserves are mostly kept in cash Debian probably > > loses at least that much to inflation each year anyway. > > This is tricky, since Debian is non-profit and selling merch can be > considered a for-profit activity. > > Having Debian funds available for merchandise will lower the barrier for > Debian people to to have it made since they don't have to invest their > own money. Debian should avoid being in the hard good business. If we want to make it easy for people to obtain Debian-branded / Debian-benefiting products, we could go with a print-on-demand service such as https://scalablepress.com/ or https://printaura.com/, using a storefront we put ourselves, use theirs, or use a 3rd party such as https://www.etsy.com. If this is to be done as 'Debian', then we will need SPI's involvement. -- Luca Filipozzi http://www.crowdrise.com/SupportDebian
scheduled downtime for Debian services at UBC (2016-01-29T06:00Z/14:00Z)
Colleagues, DSA has (just) been advised that there is a scheduled power outage at UBC that will impact Debian services. Specifically, power to the MCLD building will be disrupted, impacting Debian machines in the MCLD server room directly and in the KAIS server room indirectly. The following hosts are in the MCLD server room (power outage): * spontini.debian.org The following hosts are in the KAIS server room (network outage): * blavet.debian.org * buxtehude.debian.org * danzi.debian.org * diabelli.debian.org * elgar.debian.org * fano.debian.org * finzi.debian.org * geo2.debian.org * glinka.debian.org * gombert.debian.org * jenko.debian.org * leda.debian.net * lotti.debian.org * lucatelli.debian.org * menotti.debian.org * muffat.debian.org * nono.debian.org * reger.debian.org * sonntag.debian.org * tchaikovsky.debian.org * traetta.debian.org * tye.debian.org * ubc-bl2.debian.org * ubc-bl3.debian.org * ubc-bl4.debian.org * ubc-bl6.debian.org * ubc-bl7.debian.org * ubc-bl8.debian.org * ullmann.debian.org Thanks, Luca Filipozzi Debian System Administration -- Luca Filipozzi http://www.crowdrise.com/SupportDebian signature.asc Description: Digital signature
Re: scheduled downtime for Debian services at UBC (2016-01-23T15:00Z/24:00Z)
Please be reminded of today's outage, impacting the machines enumerated below. On Thu, Jan 14, 2016 at 07:34:15AM +, Luca Filipozzi wrote: > The following hosts are in the MCLD server room (power outage): > > * spontini.debian.org > > The following hosts are in the KAIS server room (network outage): > > * blavet.debian.org > * buxtehude.debian.org > * danzi.debian.org > * diabelli.debian.org > * elgar.debian.org > * fano.debian.org > * finzi.debian.org > * geo2.debian.org > * glinka.debian.org > * gombert.debian.org > * jenko.debian.org > # leda.debian.net > * lotti.debian.org > * lucatelli.debian.org > * menotti.debian.org > * muffat.debian.org > * nono.debian.org > * reger.debian.org > * sonntag.debian.org > * tchaikovsky.debian.org > * traetta.debian.org > * tye.debian.org > * ubc-bl2.debian.org > * ubc-bl3.debian.org > * ubc-bl4.debian.org > * ubc-bl6.debian.org > * ubc-bl7.debian.org > * ubc-bl8.debian.org > * ullmann.debian.org -- Luca Filipozzi signature.asc Description: Digital signature
Re: UBC Power Outage
On Sun, Sep 13, 2015 at 08:16:17PM +, Luca Filipozzi wrote: > There is a major power outage at UBC. > > Debian equipment and services hosted there are offline. > > Technicians have been notified. > > They estimate restoration in 4 to 5 hours. Power has been restored and most services are up. Not yet up: corelli.debian.org (mips buildd), fano.debian.org (kfreebsd-amd64 buildd) and finzi.debian.org (kfreebsd-i386 buildd). Because finicky. -- Luca Filipozzi http://www.crowdrise.com/SupportDebian signature.asc Description: Digital signature
Re: Entrepreneurial freedom for the Debian Partners Programme
On Fri, Apr 03, 2015 at 07:38:44AM +0200, martin f krafft wrote: also sprach Luca Filipozzi lfili...@debian.org [2015-04-03 04:52 +0200]: Consequently, I am in favour of a recognition mechanism that values both cash donations and service donations against the same scale, yielding a platinum/gold/silver/bronze type ranking that is reassessed annually. Something like: https://www.freebsdfoundation.org/donate/sponsors.shtml Note that this pages splits financial and hardware donations, which I understand that you don't want, right? My primary concern is recognizing organizations that provide in-kind contribution to Debian (not labour, necessarily, but services). As I said in a previous post, evaluating in-kind donations against a financial scale is possible, albeit not always easy, and the evaluation depends on many factors, including our need and a suitable market price to use. I'm prepared to accept pro-forma invoices from commercial organizations, based on their published pricing. Although it could be argued that 1RU/1Gbps of hosting is the same no matter the location of the data centre, the reality is that pricing varies widely and attempting to normalize across markets is untenable. In other words, my measuring stick is what would it have cost Debian to put a server in that data centre, based on the published pricing. For academic institutions, we can find a corresponding commercial provider in their jurisdiction / country, perhaps. With regards to fundraising, I'm in favour of using a service such as crowdrise.com -- and only one such service -- even if that means paying 3-5% (plus credit card fees, if applicable). By leveraging such a platform, we can brand our donations portal, avoid managing multiple payment processor accounts, conduct campaigns (no, not spam ... more like earmark your donation for X or Y), etc. Yes, having a micro-payment service available for payments too would be beneficial. .oO( snowdrift.coop ) .oO( BitCoin ) Finding a single service capable of providing crowdrise-like features AND a very wide variety of payment mechanisms may prove difficult. That said, we can begin our search with this as a requirement. -- Luca Filipozzi http://www.crowdrise.com/SupportDebian -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150403065725.ga3...@emyr.net
Re: Entrepreneurial freedom for the Debian Partners Programme
On Fri, Apr 03, 2015 at 10:10:11PM +0200, martin f krafft wrote: also sprach Luca Filipozzi lfili...@debian.org [2015-04-03 08:57 +0200]: I'm prepared to accept pro-forma invoices from commercial organizations, based on their published pricing. Although it could be argued that 1RU/1Gbps of hosting is the same no matter the location of the data centre, the reality is that pricing varies widely and attempting to normalize across markets is untenable. In other words, my measuring stick is what would it have cost Debian to put a server in that data centre, based on the published pricing. For academic institutions, we can find a corresponding commercial provider in their jurisdiction / country, perhaps. Absolutely, iff we need the hosting, then we can rank it according to market price. All of Debian's equipment is hosted gratis by one organization or other. However — I am not aware of prices for the type and volume of hosting required — but I'd be surprised if it'd slot in to the levels I'm imagining. I mean, look at https://www.freebsdfoundation.org/donate/sponsors.shtml and think about the market price of some of the hosting offers we get. At most, they'd probably reach Bronze, if at all. And yet, it might just be that the admins there give us special access or support because they also use Debian etc. and suddenly you cannot weigh it up against purely financial support anymore. So I don't think the solution is quite that simple and I think we shouldn't rule out the possibility to just name in-kind donations as such, rather than to slot them in with financial scales. I'm not opposed to separate in-kind and cash donation rankings. Finding a single service capable of providing crowdrise-like features AND a very wide variety of payment mechanisms may prove difficult. That said, we can begin our search with this as a requirement. I'm new to crowdrise. What's the story? It's not that I'm a proponent of crowdrise in particular. Rather, it's the feature set that's appealing. There are several operators of similar tools. And couldn't crowdrise itself be (convinced to be) interested in supporting Debian by waiving commissions on incoming donations? I doubt it: their business model is to offer non-profits a service. -- Luca Filipozzi http://www.crowdrise.com/SupportDebian -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150403210249.ga27...@emyr.net
Re: Entrepreneurial freedom for the Debian Partners Programme
Hi Martin, I recognize that you sent this to the soon-to-be DPL but I'll take the opportunity (on debian-project to leave debian-vote for possible replies from the DPL candidates) to share my thoughts. In my experience in recruiting organizations to provide services (hardware, hosting, DNS, CDN, etc.) to Debian, being able to offer ongoing acknowledgement (ie, prominent webpage such as /partners) is the single most effective tool in my toolbox (others being coordinated press releases, blog postings, and member benefits). Consequently, I am in favour of a recognition mechanism that values both cash donations and service donations against the same scale, yielding a platinum/gold/silver/bronze type ranking that is reassessed annually. Something like: https://www.freebsdfoundation.org/donate/sponsors.shtml I do not find it antithetical to FLOSS principles to acknowledge, publically, the contributions that organizations provide to Debian, be they academic institutions such as MIT or corporations such as Bytemark. With regards to fundraising, I'm in favour of using a service such as crowdrise.com -- and only one such service -- even if that means paying 3-5% (plus credit card fees, if applicable). By leveraging such a platform, we can brand our donations portal, avoid managing multiple payment processor accounts, conduct campaigns (no, not spam ... more like earmark your donation for X or Y), etc. In support, Luca On Thu, Apr 02, 2015 at 07:37:23PM +0200, martin f krafft wrote: Dear about-to-be-DPL, I know discussion period is over but Lucas encouraged me to post this now, so blame him. We've had a discussion over on -project about the revival of the Debian Partners Programme, which I hijacked into meta-level. tl;dr would be: while I am interested and want to work on this, I would only do so with enough rope, which I call entrepreneurial freedom. The thread is here: https://lists.debian.org/debian-project/2015/03/threads.html#00025 and I am particularly interested in how you would respond as DPL to my last two messages (Lucas reply included in the middle for completeness): https://lists.debian.org/debian-project/2015/03/msg00031.html https://lists.debian.org/debian-project/2015/03/msg00032.html https://lists.debian.org/debian-project/2015/03/msg00035.html PS: In this context, let me quickly also highlight my response to Paul Wise, who doesn't want Debian to turn into an advertising agency: https://lists.debian.org/debian-project/2015/03/msg00036.html I am fully aware that this is a contentious topic and the only way the project would succeed is if people can identify with it. There must not be any sell-out and we must not acquire more money than we can reasonably use towards the improvement of Debian. -- .''`. martin f. krafft madduck@d.o @martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems when a gentoo admin tells me that the KISS principle is good for 'busy sysadmins', and that it's not an evolutionary step backwards, i wonder whether their tape is already running backwards. -- Luca Filipozzi http://www.crowdrise.com/SupportDebian -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150403025251.ga28...@emyr.net
ubcece offline in 16h due to poorly scheduled power outage
On Sat, Jan 31, 2015 at 08:52:49PM +, Luca Filipozzi wrote: DSA found out a little while ago that ubcece would be offline due a scheduled power outage in the data centre. I'm heading there in 2h to turn things off. Outage is expected to begin at 23:00Z and last for 7h. Due to timezone conversion snafu with hoster, outage will actually be 16h from now lasting 8h: 2015-02-01 15:30 UTC to 2015-02-01 23:30 UTC Thanks, Luca -- Luca Filipozzi http://www.crowdrise.com/SupportDebian signature.asc Description: Digital signature
Re: ubcece offline
On Mon, Jul 21, 2014 at 09:02:09PM +, Luca Filipozzi wrote: Due to a gas leak, the buildings around the 'ubcece' data centre where Debian equipment is located have been powered down. Most Debian equipment should still be running (the exception being spontini in MCLD), as the power to the KAIS building has not been cut. The reason for outage is that the KAIS network uplinks to the campus backbone via active network equipment in the MCLD building whose power has been cut. The 'all clear' was given about 30 minutes ago and UBC IT folks are bring things back up. ubcece is online. -- Luca Filipozzi http://www.crowdrise.com/SupportDebian signature.asc Description: Digital signature
Re: Where are the May and June 2014 archives of debian-private.
On Mon, Jun 16, 2014 at 06:11:24PM +0900, Charles Plessy wrote:
Hello everybody,
plessy@master:/home/debian/archive$ cd debian-private
plessy@master:/home/debian/archive/debian-private$ ls -lahrt | tail
-rw-r- 1 debian Debian 96K sept. 30 2013 debian-private.201309.gz
-rw-r- 1 debian Debian 333K oct. 31 2013 debian-private.201310.gz
-rw-r- 1 debian Debian 79K nov. 27 2013 debian-private.201311.gz
-rw-r- 1 debian Debian 149K déc. 31 19:34 debian-private.201312.gz
-rw-r- 1 debian Debian 159K janv. 31 01:54 debian-private.201401.xz
-rw-r- 1 debian Debian 114K févr. 28 17:15 debian-private.201402.xz
-rw-r- 1 debian Debian 99K mars 29 18:08 debian-private.201403.xz
-rw-r- 1 debian Debian 211K avril 22 12:28 debian-private.201404.xz
drwxr-x--- 59 debian Debian 4,0K avril 25 20:50 ..
drwxr-x--- 2 debian Debian 12K mai4 18:34 .
plessy@master:/home/debian/archive/debian-private$
Am I missing something ?
bendel:/srv/lists.debian.org/smartlist/{debian-admin,debian-email,debian-private}/rc.forward
were configured to forward to debian-archive-$l...@debian.org rather than
debian-list-$l...@master.debian.org
I have updated them and let the listmasters know.
Luca
--
Luca Filipozzi
http://www.crowdrise.com/SupportDebian
--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140616231635.gb17...@emyr.net
Re: Intel and Debian
Hi Bryn, Thank you for contacting Debian. We're a large virtual organization with many members (Debian Developers, Debian Maintainers, etc.). You inquiry is very open-ended. It's not clear whether you're trying to reach the Debian Project Leader (Lucas Nussbaum; lea...@debian.org) or the Hardware Donation Team (me and several others; hardware-donati...@debian.org) or some other specific team or group with Debian. Let us know, Luca On Thu, Apr 17, 2014 at 08:35:36PM +, Pilney, Bryn wrote: To whom it may concern, I am contacting you on behalf of Intel's PC Client Group. Our group is taking steps to offer an affordable and compact computing experience and we have some questions for the Debian team. We are eager to start a conversation and would appreciate a response at your earliest convenience. I look forward to hearing from you soon, Bryn Pilney -- Luca Filipozzi http://www.crowdrise.com/SupportDebian signature.asc Description: Digital signature
Re: keybase.io
On Fri, Apr 04, 2014 at 02:50:01PM +0100, Jonathan Dowland wrote: keybase.io is a thing. This thing lets you, amongst other things, upload a copy of your PGP private key to their servers. This is client-side encrypted. Discuss. FWIU, the client-side encryption is javascript provided by the service so modifiable by the service at will and able to capture/transmit passphrase. DDs interested in this experimenting with this service are encouraged to NOT upload the PGP private key that is registered in the Debian Keyring. If you sign up for the beta and receive an invitation, please consider generating a new, independent PGP keypair for use with this service. For the Debian System Administration Team, Luca -- Luca Filipozzi http://www.crowdrise.com/SupportDebian signature.asc Description: Digital signature
Re: UK != GB
On Tue, Mar 04, 2014 at 10:19:44PM +0100, Jakub Wilk wrote:
Somewhere in another universe, someone noticed that many developers
have assigned country code “UK” in LDAP:
$ ldapsearch -x c=uk | grep -c ^uid:
114
But, RFC 4519, §2.2 reads: “The 'c' ('countryName' in X.500)
attribute type contains a two-letter ISO 3166 [ISO3166] country
code.”
The two-letter ISO 3166 country code for United Kingdom of Great
Britain and Northern Ireland is, somewhat confusingly, “GB”, not
“UK”.
Given the disconnect between the userdir-ldap-cgi permitted values (GB) and the
LDAP actual values (UK) and given the RFC specification for 'c', I intend to
mass update 'c=uk' to 'c=gb' in LDAP, shortly.
Complaints are best directed to the IETF and the ISO. For your protesting
convenience, the IETF are currently meeting in London UK^WGB.
--
Luca Filipozzi
http://www.crowdrise.com/SupportDebian
signature.asc
Description: Digital signature
Re: UK != GB
On Tue, Mar 04, 2014 at 09:44:41PM +, Luca Filipozzi wrote:
On Tue, Mar 04, 2014 at 10:19:44PM +0100, Jakub Wilk wrote:
Somewhere in another universe, someone noticed that many developers
have assigned country code “UK” in LDAP:
$ ldapsearch -x c=uk | grep -c ^uid:
114
But, RFC 4519, §2.2 reads: “The 'c' ('countryName' in X.500)
attribute type contains a two-letter ISO 3166 [ISO3166] country
code.”
The two-letter ISO 3166 country code for United Kingdom of Great
Britain and Northern Ireland is, somewhat confusingly, “GB”, not
“UK”.
Given the disconnect between the userdir-ldap-cgi permitted values (GB) and
the
LDAP actual values (UK) and given the RFC specification for 'c', I intend to
mass update 'c=uk' to 'c=gb' in LDAP, shortly.
Complaints are best directed to the IETF and the ISO. For your protesting
convenience, the IETF are currently meeting in London UK^WGB.
Done. Should have immediate effect in db.debian.org search.
--
Luca Filipozzi
http://www.crowdrise.com/SupportDebian
signature.asc
Description: Digital signature
Re: State of the debian keyring
On Tue, Feb 25, 2014 at 09:10:00PM +0100, Kurt Roeckx wrote: On Tue, Feb 25, 2014 at 10:51:56AM -0800, Russ Allbery wrote: Gunnar Wolf gw...@gwolf.org writes: Ian Jackson dijo [Mon, Feb 24, 2014 at 05:57:57PM +]: I think this is a bug. It can increase security because it can make operations more convenient at the same level of security, and because people trade off convenience for security. For example, it would be possible to have one key for email encryption and a different (more secure) key for package uploads. Debian tools don't care which key you use for email encryption. Except for project DPL votes, no? I think the keys are used for voting and the email interfance for db.debian.org. I'm not sure if we have any other services checking the gpg signatures of emails. echelon checks the keyring, also. -- Luca Filipozzi http://www.crowdrise.com/SupportDebian signature.asc Description: Digital signature
Re: Re: Donations to Debian are too difficult
Hi, Per http://www.spi-inc.org/donations/, PayPal donations may be made through Network For Good: https://www.networkforgood.org/donation/ExpressDonation.aspx?ORGID2=11-3390208 Thanks! Luca On Thu, Feb 13, 2014 at 10:39:51PM +0100, Gisela Neira wrote: I want to how I can donate Dabian Proyect per paypal..., please... Thanks, Gisi -- Luca Filipozzi http://www.crowdrise.com/SupportDebian -- 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/20140213223734.ga22...@emyr.net
Re: Possibly moving Debian services to a CDN
On Fri, Feb 07, 2014 at 02:08:26PM +0100, Lucas Nussbaum wrote: On 30/01/14 at 13:53 +0100, Tollef Fog Heen wrote: ]] Tollef Fog Heen Hi all, - the various bits and bobs that are currently hosted on static.debian.org I thought it's time for a small update about this. As of about an hour ago, planet and metadata.ftp-master are now served from the Fastly CDN, and it all seems to be working quite smoothly. We've uncovered some bits we want to make work better, such as adding and removing backend servers automatically when they become unavailable or are added to the static DNS RR, purging content from the caches when it's updated and possibly some other minor bits. This does sadly mean we don't currently have IPv6 for those two services, something that's being worked on by Fastly. As for the privacy concerns raised in the thread, I've had quite a lot of discussions with Fastly about how they operate wrt privacy. They don't store request-related logs (only billing information), so there are no URLs, cookie, client IPs or similar being stored. Varnish has an ephemeral log which they go through a couple of times a minute where some of that information is present, but it never leaves the host (unless we enable logging to an endpoint we control). I'm quite content with how they're handling the privacy concerns. In the interest of full disclosure I should also mention that I'm starting to work for Fastly in a few days time. I don't believe that has influenced my views or judgements here. Hi Tollef, Thanks a lot for this status update. I'm very much in favor of exploring ways to make the Debian infrastructure easier to manage, and using a CDN sounds like a great way to do so. It's great that things worked out with Fastly (any plans for a more public announcement?). However, in [1], I raised one main non-technical concern that is not mentioned in your mail: I fear that, by moving to CDNs without ensuring that there are a sufficient number of CDN providers willing and able to support Debian, we could end up in a lock-in situation with a specific CDN provider (after all, there are not so many of them, and even a smaller number could be able to deal with our technical requirements). [1] https://lists.debian.org/debian-project/2013/10/msg00074.html Of course, as long as we have the infrastructure to go back to the old way of doing things, it is not a big problem. So I'm not worried at the moment. But one of the end goals of using CDN is to reduce the number of Debian PoP (have Debian machines in a fewer number of datacenters, to make them easier to manage). Once we do that, it will be very hard to go back. Have you been trying to reach out to other CDN providers about supporting Debian? I know of discussions with Amazon CloudFront, but I remember some technical blockers? Could the DPL be of some help to you in that process? I am in active discussion with another CDN provider and I should restart the CloudFront conversation. There are technical considerations with Fastly, also, that Tollef will work through. We've always been of the opinion that we need two CDN providers. We're just as concerned about vendor lock-in as anyone. Thank you for the offer of DPL help. I'll loop you in. Luca -- Luca Filipozzi http://www.crowdrise.com/SupportDebian signature.asc Description: Digital signature
Re: Debian services and Debian infrastructure
not a private list for DSA or anything. Not sure where the word pollute or its scare quotes have come from, but it sure feels hostile. I'll assume you don't mean it that way. I have some operational questions about this cloud setup, since it seems you've delegated running Debian owned machines to us and then gone and got some that you don't want us to run. I'm not sure what to do with that disjuncture. We, we haven't said that we wouldn't talk to VPS providers. We've said that we're more interested in a bytemark-style donation of (real) hardware rather than virtual machines (since an insecure hypervisor is an insecure virtual machine - see openssl). That said, vendors like rackspace have private cloud offerings that might be the best of both worlds (we'd have to learn more about their configuration). And I actively engaged other DDs regarding their VPS opportunities (although no response so far in some cases). So, to me at least, the DPL engaging with equipment donors (real or virtual), beyond the initial securing of a positive relationship, for the possible development of debian.org services is not kosher. It actively fractures the landscape. My thoughts, Luca -- Luca Filipozzi http://www.crowdrise.com/SupportDebian signature.asc Description: Digital signature
Re: Debian services and Debian infrastructure
On Tue, Jan 21, 2014 at 05:22:28PM +0100, Lucas Nussbaum wrote: On 21/01/14 at 15:47 +, Luca Filipozzi wrote: And I actively engaged other DDs regarding their VPS opportunities (although no response so far in some cases). Oh, that's great! I've just sent you a private mail to share my contacts. I really had no idea that you intended to work on that, given that when we discussed related topics in June and again in December, you showed little interest in exploring such setups. It would have avoided some duplicate work if you mentioned it when I talked about it in [1]: | As you know, Amazon provides Debian with free credits on the | AWS Cloud. Those credits are normally used for archive rebuilds, but | have already been used by a GSOC project (PTS rewrite), and more | recently, to start work on an archive-wide autopkgtest setup. A few more | virtual machines could be accomodated, and I will investigate if we | could extend that even more. Also, codesearch.d.n is hosted on | Rackspace's Cloud[1]. I will also follow up on that. [1] https://lists.debian.org/debian-project/2014/01/msg00010.html My conversations were more in the context of finding resources for snapshot.debian.org storage (which means one VPS with lots of storage) than in the context of finding generic virtual machines (cutely, my tweet garnered more response than my other actions). The more generic one you were carbon copied on. I suggest that your private discussions with VM providers should have been discussed with (or at least disclosed to) DSA. (There is little value in this you should have tit for tat so I'll stop here.) I'm worried that we're heading down a path that we've seen before: individual DDs obtain resources under the banner of Debian with single DD access and with no record of the donation. As DPL, you are acting officially compared to the above but this is what I meant by fractured landscape. Not all my colleagues want to be involved, to be sure, in managing VPS resources but having them documented and allocated (ie managed) is important. I don't think that that is a (useful) DPL task. So, if it isn't DSAs, make it Auditors or somebody's. In other words: don't fracture the landscape. But if you're going to, make sure it's managed. -- Luca Filipozzi http://www.crowdrise.com/SupportDebian signature.asc Description: Digital signature
Re: Debian services and Debian infrastructure
On Mon, Jan 06, 2014 at 10:16:20PM +0100, Daniel Pocock wrote: On 05/01/14 14:55, Stefano Zacchiroli wrote: On Sun, Jan 05, 2014 at 02:28:59PM +0100, Joerg Jaspert wrote: Q3. What should be our definition of official services? Even if this is highly preferable, I don't think that official services (.d.o services) should necessarily be running on Debian hardware managed by DSA, provided that: - the service is clearly useful and used - the service has a sustainable maintainance model (active team + instructions on how to contribute, run a local copy, etc. + DFSG-free) - the service's design does not raise security or scalability concerns I disagree on that, official services should run under project overview. So far that the project can take it over and move it, should all of the team go away. Active team today doesn't mean they are there tomorrow to properly hand it over. Having the project itself have access (via DSA at least) ensures it can continue. I very much agree with Joerg on this. A team like DSA offers to the Debian Project two key features. One, which is the most visible one, is the technical output and continued service of a team of talented sysadmins. The other is the governance guarantee that we, as a project, can always take over the maintenance of a service whose current maintainers go MIA or become unwilling to work with the rest of the project for any reason. As Joerg points out. Disclaimer/conflict of interest: I'm currently proposing a lightweight SIP service to run on DSA maintained infrastructure For any service, there are some general issues that come to mind for me: a) credentials: many services need TLS certificates these days. debian.org private keys probably have to be on boxes that DSA control and secure and not floating around in shared cloud storage or outsourced boxes at arms length agreed b) delegated services: that said, some types of application can delegate their security checks (e.g. SIP can use a RADIUS server to verify DIGESTs). In these situations, the service hosting equipment does not need to have any copy of the user credentials. The verifications are made in the RADIUS server. By exposing services such as RADIUS, DSA could allow other people to run servers that don't need any copies of keys or credentials on their local disks. we're also concerned about which passwords are entered where; hence sso.debian.org and the desire to keep distinct the password used for SIP/XMPP from that used for sudo -- Luca Filipozzi http://www.crowdrise.com/SupportDebian signature.asc Description: Digital signature
Re: Debian Enhancement Proposals website temporarly broken.
On Fri, Dec 27, 2013 at 12:33:40AM +0100, Andreas Tille wrote: Hi, On Thu, Dec 26, 2013 at 07:33:41PM +0100, Martin Zobel-Helas wrote: assuming the content is entirely static, we could move dep.debian.net to dillon.debian.org. What about using dep.debian.org? I think that's they idea. The underlying box is dillon. That's where a number of static debian.org websites live. -- Luca Filipozzi http://www.crowdrise.com/SupportDebian -- 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/20131227025121.ga10...@emyr.net
Re: Should mailing list bans be published?
On Sat, Oct 26, 2013 at 10:46:41AM -0700, Steve Langasek wrote: Hi folks, Was discussing with one of the listmasters (Alexander Wirt) on IRC today about mailing list bans, because it turns out that someone I was just about to ask the listmasters to ban from debian-devel had just been blocked in response to a request from someone else. This led to a philosophical debate about whether bans should be made public. Alexander expressed concern that having them published could be harmful to a person's reputation, since employers will google your name and see that you've been banned from a large project such as Debian. I think we should publish them, for several reasons: - Debian is not responsible for the reputation of someone who has gotten themselves banned for their behavior; their reputation is already in the mud if employers read their actual posts to the Debian lists. - It brings closure to the rest of our community to know that action has been taken against an abuser, showing that we've stood up for the principle of civil discourse and that the problem hasn't just gone away on its own because a troll got bored. - It gives Debian contributors confidence that bad behavior doesn't have to be silently endured as a cost of participating in Debian lists. - It improves *Debian's* reputation to the rest of the world, by showing that our mailing lists are not anything goes. - It provides a reference point for newcomers to the Debian community to judge their actions by, to understand what kinds of things will get them banned from participation (although I expect few of the people who need such guidance will actually take advantage of it...) - It casts sunlight on the kinds of decisions that the listmasters are making WRT bans, so that we collectively have oversight of these decisions and can ensure our principles are being applied fairly and consistently. So I don't think bans need to be posted anywhere prominent like debian-devel-announce, but I do think basic facts like who is banned, for how long, and the rationale (with links to specific mailing list posts as reference) should be made public. What do the rest of you think? The counterargument would be that disclosing our reasons for a ban might show us as capricious ... which is yet another reason to publish the bans so that we are also held to account for our decisions. If the above is unclear: I'm in favour of publishing our decisions to ban. -- Luca Filipozzi http://www.crowdrise.com/SupportDebian -- 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/20131026180913.ga27...@emyr.net
Re: Should mailing list bans be published?
Bart wrote: The harm that could come to Debian's reputation is that Debian could be perceived as an organization that harms people's reputation by judging them in public about their behavior on the mailing lists. Steve replied: Ok, thanks for explaining. This isn't something that concerns me at all, but I understand that it concerns you. Paul agreed: Nor I. The fact of the matter is that forcing folks to think twice before posting complete garbage to the mailing lists is nothing but good. If we get the reputation for harming the reputations of folks who harass and abuse others, well, fine by me -- just don't troll the MLs. I think that our reputation is harmed more by mailing list archives containing argumentative / vitriolic emails than by a reasoned (!) declaration of a ban. The public publication of the ban cuts both ways. If the reasoning behind the ban is sound, then it will enhance our reputation for all the reasons already mentioned by Steve and others; if it is not, then our reputation is damaged, and appropriately so. Public publication keeps both discussion participants AND listmasters in check. -- Luca Filipozzi http://www.crowdrise.com/SupportDebian signature.asc Description: Digital signature
Re: Report from GanetiCon 2013 in Athens
Hi, On Mon, Sep 09, 2013 at 11:38:45AM +0300, vangelis mouhtsis wrote: I live in North Greece Thessaloniki and here we have the biggest Debian community. I'm wondering why was non announcement for that event at all. Or maybe it is a natural behavor? GanetiCon is not a Debian event. It just happens that a Debian person or two attended and are writing a report. Also, Martin did announce his attendance in advance: https://lists.debian.org/debian-project/2013/08/msg00065.html Regards, Luca -- Luca Filipozzi http://www.crowdrise.com/SupportDebian -- 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/20130909092653.ga24...@emyr.net
Re: [Debian-sponsors-discuss] Donations to Debian are too difficult
On Sun, May 05, 2013 at 06:31:14PM -0500, Michael Shuler wrote:
To add an additional thought, why not use the services of one of
Deb{ian,Conf}'s major sponsors, and why not offer multiple one-click
donation options to give users a choice?
https://checkout.google.com/seller/npo/
And we could consider leveraging CrowdRise (or Network For Good directly) as a
social fundraising platform.
Be the first to give! (see sig)
--
Luca Filipozzi
http://www.crowdrise.com/SupportDebian
--
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/20130506023404.ga24...@emyr.net
[ubcece] notice of planned outage 2013-03-25T13:00Z/14:00Z
Hi, As previously announced [1]: 2013-03-25T13:00Z/14:00Z [2]: ubcece outage for installation of additional circuits (not for Debian) in the server room where Debian's infrastructure is located; same set of services impacted as listed in [3] Questions / comments to debian-ad...@lists.debian.org (DSA + local/service admins) or debian-ad...@debian.org (DSA only). Thanks, Luca [1] https://lists.debian.org/debian-infrastructure-announce/2013/03/msg2.html [2] http://www.timeanddate.com/worldclock/fixedtime.html?msg=ubcece+outage+for+electrical+circuit+installationiso=20130325T06p1=256ah=1 [3] https://lists.debian.org/debian-infrastructure-announce/2013/03/msg1.html -- Luca Filipozzi http://www.crowdrise.com/SupportDebian signature.asc Description: Digital signature
Re: RFC - Changing current policy of debian.net entries
On Sat, Jun 23, 2012 at 12:45:02PM -0500, Raphael Geissert wrote: I think you are combining two different issues: debian.net namespace and how new projects are developed/introduced. ... If you and others agree that there are two different topics that should be discussed and their respective policy drafted, then I would be happy to join the discussion. I'm all open for it. I agree with both Martin's original points and Raphael's clarifications regarding (1) separating the concerns relating to the debian.net zone versus introduction of new services, and (2) using the more welcoming phrase 'incubating' rather than 'unofficial'. To be fair to Martin, we discussed (very briefly) 'unofficial' vs 'incubating' and I suggested using unofficial. Like Martin, I'm keen on simultaneously encouraging developer engagement / ingenuity while avoiding debian.net / debian.org confusion (or embarrassment, as Raphael suggests, in some cases). -- Luca Filipozzi -- 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/20120623181626.ga18...@emyr.net
Re: UBC-ECE maintenance window June 9th/10th
On Sat, Jun 09, 2012 at 11:51:15PM +0300, Touko Korpela wrote: Peter Palfrader wrote on debian-infrastructure-annou...@lists.debian.org: Our friendly hosting partners at the Department of Electrical and Computer Engineering of the University of British Columbia (UBC-ECE) have advised us of maintenance work being conducted this Saturday, the 9th of June. This announcement should have cc:d to other mailing lists too. Not many people read debian-infrastructure-announce (maybe they should). Yes, they probably should. The entire propose of d-i-a is to make announcements regarding changes and (hopefully scheduled) outages. Hope that recent plans for spending Debian money make more services location redundant so that not single outage takes service offline. All external (public) services are redundant. Internal services aren't and probably don't need to be so long as they can be restored in a reasonable time-frame. Cheers, Luca -- Luca Filipozzi Member, Debian System Administration Team -- 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/20120609225357.ga19...@emyr.net
Re: Long-term hardware replacement planning (Re: (deferred) bits from the DPL: March 2012)
--- man-daczerny HP DL380 G7 2011-11-02 HP DL380 utwente klecker HP DL380 G7 2011-11-02 HP DL380 accumupettersson Supermicro 2009? New acquistions, by year: 2012: Where MachineHardwareComment --- man-da(new man-da 1) HP DL380VM host ubcecegiustini5 addtl disks fully populate current HP MSA shelf ubcecestrozzi network switch ubcece(new ubcece 1) HP BL460c dedicated to udd ubcece(new ubcece 2) HP BL460c dedicated to bugs-mirror ubcece(new ubcece 3) HP BL460c VM host (already donated) ubcece(new ubcece 4) HP BL460c VM host (already donated) 2013: Where MachineHardwareComment --- grnet (new grnet 1) HP DL380VM host grnet (new grnet 2) HP DL380VM host grnet (new grnet 3) network switch ubcecegiustiniHP MSA shelf w/ 6 disks 2015: Where MachineHardwareComment --- grnet (new grnet 4) HP DL380VM host; only if needed grnet (new grnet 5) HP DL380VM host; only if needed -- 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/87vckwx2b3@qurzaw.varnish-software.com -- Luca Filipozzi signature.asc Description: Digital signature
Re: Diversity statement for the Debian Project
On Sat, Apr 07, 2012 at 12:23:21PM +0200, Enrico Zini wrote: On Thu, Apr 05, 2012 at 10:32:21PM +0200, Francesca Ciceri wrote: It doesn't matter how you define yourself or how others define you: we welcome you. We welcome contributions from everyone Moar nitpicking: s/define/perceive/g That gives: It doesn't matter how you perceive yourself or how others perceive you: we welcome you. This is after feedback from a respected friend on a private IRC channel, who pointed out that the concept of definitions has unwelcome connotations. The first 'define' might want to be 'identify' and the second 'perceive' for It doesn't matter how you identify yourself or how others perceive you: we welcome you. Or possibly: It doesn't matter how you choose to identify or how others perceive you: we welcome you. Cheers, Luca -- Luca Filipozzi signature.asc Description: Digital signature
Re: Diversity statement for the Debian Project
On Sat, Apr 07, 2012 at 06:57:47PM +0200, Steffen M?ller wrote: I am starting to enjoy this. On Sat, Apr 07, 2012 at 11:03:07PM +, Luca Filipozzi wrote: On Sat, Apr 07, 2012 at 12:23:21PM +0200, Enrico Zini wrote: On Thu, Apr 05, 2012 at 10:32:21PM +0200, Francesca Ciceri wrote: It doesn't matter how you define yourself or how others define you: we welcome you. We welcome contributions from everyone Moar nitpicking: s/define/perceive/g That gives: It doesn't matter how you perceive yourself or how others perceive you: we welcome you. This is after feedback from a respected friend on a private IRC channel, who pointed out that the concept of definitions has unwelcome connotations. The first 'define' might want to be 'identify' and the second 'perceive' for It doesn't matter how you identify yourself or how others perceive you: we welcome you. Or possibly: It doesn't matter how you choose to identify or how others perceive you: we welcome you. And what about a bit of a simplification: It does not matter who you or who others think you are: we welcome you. i wanted to put 'identify' into discussion but please don't interpret this reply as my being insistent on the point... 'define yourself' passed my initial filter! if i had to choose: - identify/perceive - perceive/perceive - think/think - define/define -- Luca Filipozzi signature.asc Description: Digital signature
Re: revenue sharing agreement with DuckDuckGo
On Wed, Mar 28, 2012 at 10:52:49AM +0200, Steffen Moeller wrote: How much money are we talking about? Less than $5000? More? Difficult to say, between 1000 and 1? Per the recent sprint report, hardware is becoming one of the biggest expense categories for Debian. I support and applaud Stefano's effort to secure additional funding for the project. While I'd prefer having unencumberd cash donations and preferential (manufacturer's internal cost) hardware pricing, I'm willing to explore the DDG relationship, especially if we offer users the ability to opt out (or in). -- Luca Filipozzi -- 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/20120328091034.ga20...@emyr.net
Report from DSA Team Sprint in Oslo
content delivery network [3] where we have one central host to which services would submit their static content and from which it is then replicated to a set of mirror nodes around the world. The main archive is not intended to be part of this mirror network. SSO: We have been working on deploying a web-based single-sign-on solution. This will allow all users in the Debian LDAP to authenticate to various web services using a single password. It is already used by nm.debian.org and we are working with other teams to enable SSO for their respective services. There are still some technical issues outstanding as well as a lack of documentation. That said, if you run a service which could benefit from this, please get in touch. Authorization is currently out of scope for the SSO service and needs to be provided be service in question. It is not out of the question to extend this service to other authentication providers such as Alioth in the future. DR: We have worked with service owners to mitigate disaster risks by redundantly deploying services across our geographically diverse hosting locations. Nevertheless, there continue to be a number of non-redundant services that represent single points of failure. While we can virtualize many of these services, the ability to perform bare-metal recovery of service-dedicated hardware or of VM-hosting hardware is becoming a requirement. Critical portions (/etc and /srv, say) of debian.org machines are backed up using a venerable tool (da-backup) but it does not provide for bare-metal recovery. As a result, we have decided to switch to bacula. [3]: not to be confused with cdn.debian.net User and Group Management = Debian has, approximately, 50 000 shell accounts [4]. We believe most of these are unused and would therefore like to disable those that are. The goal is to reduce the our exposure and not to take away anybody's privileges. We will monitor shell account activity in order to identify and disable shell accounts that have been unused for a significant amount of time (months). We will extend ud-ldap to allow users to easily and quickly re-enable their shell accounts. Similarly, there is currently no mechanism which ensures that people only have the group memberships which they are using. We would like to implement a system which will require users to periodically confirm their group memberships. Like the shell accounts, the goal is to reduce our exposure, not to take away anybody's privileges. [4] sum of accounts across all debian.org machines Thanks for reading this far. We appreciate the opportunity to serve. If you have any question, please don't hesitate to ask, either replying to this mail on -project or contacting us at debian-ad...@lists.debian.org. Regards, Luca Filipozzi on behalf of the Debian System Administration Team -- Luca Filipozzi, Member Debian System Administration Team -- 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/20120320012015.ga19...@emyr.net
