Re: [Debconf-team] PSU Network Requirements
On Wed, Jun 4, 2014 at 8:33 PM, Kees Cook wrote: > The only hard requirement I've heard so far is that a single IP needs > unfiltered inbound connections for providing the video streaming. Is this > accurate? Does the video team need more than this? > > Not accurate. I do not need any inbound connections. > > Do we _need_ wired switches in all the rooms? If so, why? (I suspect I can > answer this one, but I want to hear other voices.) > I need a switch in each talk room to link the 3 video machines in that room together. I will need 2mbs exiting each room. It will be very nice to have access from the data center to the machines in the rooms, but with some creative configuration I can do without. ___ Debconf-team mailing list Debconf-team@lists.debconf.org http://lists.debconf.org/mailman/listinfo/debconf-team
Re: [Debconf-team] DebConf 14 registration/alioth create new account problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I have a kitt-guest and kitty-guest pending accounts, the email is ki...@kitty.in.th I activated the account, and went to the lost passwd page, so you should have received a hash to setup a new password. I deleted kitty-guest. Cheers Christian On 04/06/2014 17:36, Steve Langasek wrote: > On Wed, Jun 04, 2014 at 10:37:16AM +0700, Kitt Tientanopajai wrote: > >> I tried to create a new account on alioth to register DebConf14 on May >> 31, but did not receive any confirmation mail from alioth. I mailed >> to registrat...@debconf.org but they told me that they could not do >> much help since they don't manage the authentication system. > >> Please kindly help and guide me through. > > debconf-team also does not manage the authentication system. If you are > having difficulty creating an account on alioth, I think you will need > ad...@alioth.debian.org (added to Cc:). > > Alioth admins, do you have any trace of this attempted account creation? > According to previous discussion on IRC, the requested username was > kitt-guest, which does not show up in a username search on the website. > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlOPjlIACgkQTx4JB6685x+4DwCbBPsX/2fRtZmIMZ4gJvTgLPUV dQAAn1Pvdhgyzn6aZvNfKVoQtuUsXxCi =HMOA -END PGP SIGNATURE- ___ Debconf-team mailing list Debconf-team@lists.debconf.org http://lists.debconf.org/mailman/listinfo/debconf-team
Re: [Debconf-team] A proposal about scheduling for DC14
On Wed, Jun 04, 2014 at 12:56:53PM +, Clint Adams wrote: > On Wed, Jun 04, 2014 at 07:40:12AM +0100, Jonathan McDowell wrote: > > Are you both saying we should go with Steve's original suggestion: > > > > http://lists.debconf.org/lurker/message/20131001.175026.0a50b91b.en.html > > I would probably swap Thursday and Friday but in the interest of > not discussing it I'll just say yes. Similarly -- I rank the original proposal above the later suggestions, due to the reasons I stated before. I can argue about the exact shade of paint if you want: I agree with Clint's point, and would also prefer to rephrase things with the BOF vs. talk distinction made in the later proposal. (I would also see that level of detail as fine to delegate to whoever prepares a final version.) Moray ___ Debconf-team mailing list Debconf-team@lists.debconf.org http://lists.debconf.org/mailman/listinfo/debconf-team
Re: [Debconf-team] PSU Network Requirements
Kees Cook dijo [Wed, Jun 04, 2014 at 06:33:55PM -0700]: > Hi, > > I talked on the phone today with the head of the PSU network. I can't say I > have good news at all. Umh, right. Although they can be seen in a good light: This saves us from the work of setting up the network :) > They don't want us setting up our own wifi network because it will > collide with theirs. The /16 they'd mentioned is for their entire campus, > not just for our conference. Their guest wifi network is a captive > portal that needs email registration on a per-MAC per-day basis. All > externally-initiated traffic is blocked. Their wifi and wired networks are > separate segments. The main thing that worries me here is that I've seen very few Wifi setups where the infrastructure is adequate for the density we usually handle. Yes, also in DebConf we have saturation problems, but at least we know our guys know their way setting up APs in the right channels to minimize the problem (and whatever other configmagic I do not know about). Can PSU provide at least the facility for their network admins to do the needed changes if they are pointed out? How many APs do they have per working space? We could consider having enough switches and cables for people to connect, in order to avoid starvation syndrome. > What they can do: > > - light up 1 port per conf room with access to their wired network > - disable port security for our rooms so we can add our own switches > - add hardcoded MACs to the wifi guest ACL that avoids the captive portal > - support thousands of people on their wifi network If this is so (and *done properly*), I think we won't have much problems. If they can set up *more than* one port, that would be great — If for nothing else, to separate video streams from regular traffic. We can ask attendees to provide their MAC addresses beforehand, so we are all on the ACL whitelist by the time we get there? I don't see the captive portal as much of a problem, unless it's one of those captive portals that kicks you out and drops your connections too often (but if you say it requires one login a day, it's not that bad). > (...) > Do we _need_ to have arbitrary inbound access? If so, why? It's nice to have, but we don't _need_ it, and we have often not had it. > Do we _need_ wired switches in all the rooms? If so, why? (I suspect I can > answer this one, but I want to hear other voices.) I'd say, yes. Because wireless is much fail-prone. Also, because several people come with devices other than laptops they want to work on, and those devices don't always have a wireless interface. > Do we expect to host an archive mirror or other services somewhere on > the wired network? If so, why? It would be good. Because having a mirror strongly reduces network load — Some hundreds of Debian people working on Debian time will be hammering ftp.us.debian.org otherwise. > If we bring in an ISP, it's going to get messy and costly. I would > really like to avoid this, but it seems to be our only fallback if we > can't live peacefully on their existing infrastructure. IIUC, they peer > with at least with Integra. Possibly ComCast. I'm getting an up to date > list shortly. I don't think we will need an external ISP. ___ Debconf-team mailing list Debconf-team@lists.debconf.org http://lists.debconf.org/mailman/listinfo/debconf-team
Re: [Debconf-team] A proposal about scheduling for DC14
On Wed, Jun 04, 2014 at 08:03:33AM -0700, Patty Langasek wrote: > On Tue, Jun 03, 2014 at 11:38:36PM -0500, Gunnar Wolf wrote: > > > So, yes, if we have to decide between three days of mostly-hackning > > (read: What was previously known as DebCamp) and three days of > > mostly-conference (read: What was previously known as DebConf), I > > think the point pushed by the local team about DebCamp not being a net > > benefit for Debian would defeat itself. Interleaving mostly-talks and > > mostly-hacking days would at least introduce a change that could in > > some way be evaluated. > > I don't believe that the point "pushed by the local team about DebCamp not > being a net benefit for Debian would defeat itself", because that doesn't > take into account how we attempted to restructure "DebCamp" to ensure more > people could participate without increasing a cost to Debian. > > DebCamp is expensive. DebCamp, as it existed, had no way to ensure those who > were attending were held accountable for being hosted, on Debian funds, to > collaborate with others. And, as an organizer, I've received multiple > complaints from people who *fully expected* to be able to collaborate with > others who were hosted at a DebCamp, and the others were no where to be > found, and the report back was that they were indeed *not* hacking. > > I know this is not true for everyone, but this is most certainly a case > where a few people have "ruined" the situation for everyone, and we *need* > to find a way to actually make this work. I will point out that I have > REPEATEDLY offered to help organize any sprints that people would like to > have in Portland before (or after) the conference proper, and Lucas has > offered to sign off on any of those sprints. To my knowledge, NOBODY has > gone through the process to request a sprint. This suggests to me that > DebCamp really was more about convenience than actually planning on > collaboration. > > So, the local team for DC14 chose to attempt to incorporate DebCamp *into* > DebConf to address this issue. If it will work or not is what we'll see > after August. > > And, quite frankly, I'm extremely insulted by the attitude of those who have > been crying out about the lack of a DebCamp and declaring that the lack is a > "bug" from DC14's planning, but haven't been bothered to even *apply* for a > sprint. If this were sincerely about needing to collaborate, I would expect > at least one sprint to be requested. None have. NONE. NOT. A. SINGLE. > ONE. Hacking on debcamp is not the same as doing a sprint. In debcamp we know that many people from different fronts in Debian will be there, and such inter-teams collaboration is important. Also, being debcamp an 'official' part of the Debian anual conference makes things easier for those who need to justify days off from school/job/whatever. In debcamp, random hacking sessions also happen, without any previews work plan. It happened to me to do totally different work from what I've planned just because I found other people working on things that were much more motivating to me at that time. It also happened to be called by others to help with large bunch of missing translation, which I doubt I could do in my 'regular' days at home. I see the same happing with others many times. > If DebCamp is that sincerely important to your team, or coordination of a > couple of teams, REQUEST A SPRINT FROM LUCAS. CLEARLY if DebCamp was so > important, we would be OVERWHELMED with sprint requests! But, we haven't. Sprints can be request over the year, it doesn't need to be just before/after Debconf. Debcamp is not sprint, this assumption is wrong. And this difference does not mean that debcamp is free vacation. It's unfair, really, reading such a comment (from steve) as response to someone (gregor) we know does lots of hard work in debcamp is more than disturbing. > So, please help us figure out how to actually incorporate *hacking* with > *talks*. I don't have a strong opinion about this new DC format, I hope I have one after the conference. I feel it was not much discussed before being decided, that's the main problem to me, sorry if I'm wrong. My general comment on this is that once the thing is done, let's do it in a way we can compare it to the traditional format in the end, so having alternate sessions, as proposed originally, or the mixed proposal, which looks reasonable to me as well -- for the purpose. Regards, -- .''`. Tiago VazGPG : 1024D/A504FECA : :' : http://acaia.ca/~tiago XMPP : tiago at jabber.org `. `' tiago at debian.org IRC : tiago at OFTC `-Debian GNU/Linux - The Universal OS http://www.debian.org
Re: [Debconf-team] [Debconf-discuss] Prices?
On Thu, Jun 05, 2014 at 04:29:14PM +, Solveig wrote: > I read > https://lkuper.github.io/blog/2014/05/31/your-next-conference-should-have-real-time-captioning/ > yesterday, and there is a conference for which I'd be interested: > Debconf, in Portland, August 23-31 [1]. It's a conference about Debian, > a GNU/Linux operating system. > [1] http://debconf14.debconf.org/ > So I sent an email to the organizers, Erm, not according to my mailbox you didn't? The organizers are at debconf-team@, not debconf-discuss@ :) > and they say it depends on the prices. The only response I saw to your mail to debconf-discuss was p2mate saying "yes, if you pay for it", which is not at all the same thing as the DebConf team saying that DebConf will pay for it depending on the price. I have no objection to you looking into this possibility, I just want to be clear that there's nothing in the approved DebConf14 budget for this, and unless it can be done very cheaply, it seems unlikely to me that we would be able to add it in at this late stage of planning. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature ___ Debconf-team mailing list Debconf-team@lists.debconf.org http://lists.debconf.org/mailman/listinfo/debconf-team
Re: [Debconf-team] PSU Network Requirements
Kees, Thanks for following up on this. While the answers weren't the ones we were hoping for, I don't think the situation is all that bad... I see several ways we can still make this work. On Wed, Jun 04, 2014 at 06:33:55PM -0700, Kees Cook wrote: > I talked on the phone today with the head of the PSU network. I can't say > I have good news at all. > They don't want us setting up our own wifi network because it will > collide with theirs. The /16 they'd mentioned is for their entire campus, > not just for our conference. I don't think there's any requirement for the wifi to hand out public IPs. So scarcity of public IPs should not be an issue, as long as they understand that a /24 for the wifi DHCP pool is *not* going to be sufficient. > - light up 1 port per conf room with access to their wired network > - disable port security for our rooms so we can add our own switches > - add hardcoded MACs to the wifi guest ACL that avoids the captive portal > - support thousands of people on their wifi network That mostly sounds ok to me. > Non-negotiable items: > - they will not allow us to set up unauthenticated bridged wifi to their > wired network since this exposes campus services to the outside world. What does "unauthenticated" mean here? Are APs with a shared WPA passphrase sufficient? (This is what we've used in the past for DebConf.) If they're going to allow us to run our own switches, I don't see any significant difference between this, and WPA-PSK-secured wifi. OTOH, if we have to accept a captive portal on the wifi, I'm not sure that's a blocker (even if it doesn't make sense to me) as long as we have wired ports available. > Do we _need_ to not have a captive portal on the wifi? If so, why? TTBOMK no, but don't take my word as authoritative. > Do we _need_ to have arbitrary inbound access? If so, why? > Do we _need_ wired switches in all the rooms? If so, why? (I suspect I can > answer this one, but I want to hear other voices.) We do need wired switches in the hacklabs, and the video team will need wired ports for their transport in the talk rooms. For the hacklabs, the switches are used both to reduce wifi contention, and to allow people to hack on devices that may not have wifi. This includes hacking on embedded systems (e.g., we have a sponsor this year who wants to set up some demo machines which are not going to be wifi), and also hacking on the Debian installer, which has no support for captive portals. > Do we expect to host an archive mirror or other services somewhere on > the wired network? If so, why? We normally rely on having a full local Debian mirror in order to minimize upstream bandwidth consumption. I know that PSU already *has* a local Debian mirror, so this may not be an issue. If PSU can arrange transparent proxying to redirect to their mirror (which I believe is what we've traditionally done at DebConf), we can potentially save the university some bandwidth and improve QoS for the conference. If PSU doesn't care about the bandwidth use, then we can probably make do without a transparent proxy; but having one would still improve overall latency for the conference. (To be sure, I fully expected that this year we would want to redirect to mirrors.cat.pdx.edu rather than porting in a separate conference mirror.) Personally, my only real concern in all of this is that PSU may severely underestimate the device density, and their wifi infrastructure may not actually be up to the task. I expect the device-per-person ratio to be about 2:1 for DebConf. While SMSU has hosted conferences of Open Source folks before (e.g. Linux Plumbers), it's been several years now, and smartphones are much more ubiquitous - and I think the Debian audience is much less likely to fall back to wireless connectivity for their devices in the face of contention than a more US-centric attendee base might. So as has already been mentioned, we should figure out if their AP density is really up to the challenge of handling 500+ simultaneous wifi connections in this space. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature ___ Debconf-team mailing list Debconf-team@lists.debconf.org http://lists.debconf.org/mailman/listinfo/debconf-team
Re: [Debconf-team] PSU Network Requirements
>> - they will not allow us to set up unauthenticated bridged wifi to their >> wired network since this exposes campus services to the outside world. > > What does "unauthenticated" mean here? Are APs with a shared WPA passphrase > sufficient? (This is what we've used in the past for DebConf.) If they're > going to allow us to run our own switches, I don't see any significant > difference between this, and WPA-PSK-secured wifi. OTOH, if we have to > accept a captive portal on the wifi, I'm not sure that's a blocker (even if > it doesn't make sense to me) as long as we have wired ports available. > >> Do we _need_ to not have a captive portal on the wifi? If so, why? > > TTBOMK no, but don't take my word as authoritative. One thing to consider is their captive portal authentication can takes several minutes in the best circumstances. Last time I used their captive portal it took about ten minutes to receive the verification code. If the are concerned about exposing services by having a open AP's we could secure them and also enable client isolation so access to their WAN is not an issue. But then there is their concerns of wifi interference... If were using AP's in the just the areas were actually leasing and their not long range idk why this is an issue at all. > >> Do we _need_ to have arbitrary inbound access? If so, why? > >> Do we _need_ wired switches in all the rooms? If so, why? (I suspect I can >> answer this one, but I want to hear other voices.) > > We do need wired switches in the hacklabs, and the video team will need > wired ports for their transport in the talk rooms. For the hacklabs, the > switches are used both to reduce wifi contention, and to allow people to > hack on devices that may not have wifi. This includes hacking on embedded > systems (e.g., we have a sponsor this year who wants to set up some demo > machines which are not going to be wifi), and also hacking on the Debian > installer, which has no support for captive portals. > >> Do we expect to host an archive mirror or other services somewhere on >> the wired network? If so, why? > > We normally rely on having a full local Debian mirror in order to minimize > upstream bandwidth consumption. I know that PSU already *has* a local > Debian mirror, so this may not be an issue. If PSU can arrange transparent > proxying to redirect to their mirror (which I believe is what we've > traditionally done at DebConf), we can potentially save the university some > bandwidth and improve QoS for the conference. If PSU doesn't care about > the bandwidth use, then we can probably make do without a transparent proxy; > but having one would still improve overall latency for the conference. > > (To be sure, I fully expected that this year we would want to redirect to > mirrors.cat.pdx.edu rather than porting in a separate conference mirror.) > > Personally, my only real concern in all of this is that PSU may severely > underestimate the device density, and their wifi infrastructure may not > actually be up to the task. I expect the device-per-person ratio to be > about 2:1 for DebConf. While SMSU has hosted conferences of Open Source > folks before (e.g. Linux Plumbers), it's been several years now, and > smartphones are much more ubiquitous - and I think the Debian audience is > much less likely to fall back to wireless connectivity for their devices in > the face of contention than a more US-centric attendee base might. So as > has already been mentioned, we should figure out if their AP density is > really up to the challenge of handling 500+ simultaneous wifi connections in > this space. I have concerns about their AP's scaling too as it is they do some heavy rate limiting behind the scenes. ___ Debconf-team mailing list Debconf-team@lists.debconf.org http://lists.debconf.org/mailman/listinfo/debconf-team
