infrastructure March 2013

infrastructure@lists.fedoraproject.org

25 participants
26 discussions

report_mirror is where?
by Christopher Meng 14 Mar '13

14 Mar '13

Hi, can anyone update the page for mirroring? https://fedoraproject.org/wiki/Infrastructure/Mirroring I will setup a mirror for fedora, but a "public" mirror seems not easy..... Thanks! -- *Yours sincerely,* *Christopher Meng* Got problems with Windows? - ReBoot Got problems with Linux? - Be Root Ambassador/Contributor of Fedora Project and many others. http://cicku.me

3 6

Meeting Agenda Item: Introduction Akshay Sharma
by Akshay Sharma 12 Mar '13

12 Mar '13

Hello Everyone, My name is Akshay Sharma and i am a beginner IT Student in India.My age is 19 years. I am really interested to work with the fedora project community.I know programming in java and C++ and are interested in the development work for Fedora.I like to join the Infrastructure team to provide support to other team members and community. Since i don't have any great prior experience but i will try to learn as much as possible with your help and will give my best that i can do for the Fedora Community Akshay Sharma

1 0

Oauth -- shall we start using this?
by Toshio Kuratomi 12 Mar '13

12 Mar '13

So in the past week a bunch of us have been talking about API Keys, OAuth, passwords, and other means of managing authn and authz in the web apps that are up and coming (specifically mentioned were copr and datagrepper). Puiterwijk has put in some time reading the OAuth specifications and on Friday he walked me through how OAuth is supposed to work. I'll give a summary of his talkl here and then we can kick off some discussion. OAuth is a standardized method for a user to grant access to resources that they own to people and things that are not themselves. Currently this is being used to allow a user to control the access to data and actions that may be performed on one web service by another web service. The concepts and mechanisms can be used in any situation where the user wants to limit what the software they are using can do on their behalf. = Part I: What is OAuth? = == Let's name all the things == * Protected Resource is either data or a function that you want to use. * Resource Server is the server that hosts the data. * Client is the program that needs access to the Protected Resource. * Resource owner is the person (may also be a system but well concentrate on actual people for this summary) who is authorized to grant clients access to the Resource. * Authorization Server is the server that grants tokens and codes. .. note:: `access` is used to mean that the client can use the protected resource. That usage might cause changes to data or cause other actions to be taken (like kicking off a build). be careful not to read `access` as "ability to read the data". Example time: There's a resource called 'full name of toshio'. It's hosted on the Fedora Account System so FAS is the resource server. Since toshio is my account, I am the resource owner for it. When I log into the PackageDB, PackageDB wants to display my full name to greet me. PackageDB needs to contact FAS for that information. Thus PackageDB is the client. If we create an OAuth server, that server will be the Authorization Server that verifies my identity and asks me to grant access to 'full name of toshio' to the PackageDB. Once I've done so, it will issue the tokens and codes that actually let the PackageDB get the information it wants from FAS. == Flow of a basic request from start to finish == * The client program needs to get access to a protected resource. * The client asks the authorization server for a client-id and tells the server which permissions it needs * The authrization server gives a url to the client * The client program redirects the user to that url so the user can grant permissions to the client * The authorization server authenticates the user (ie: they login to the authorization server). * The authorization server asks the user to confirm they want to grant the requested permissions to the client. * If the answer is no, the protocol ends. * If he answer is yes, the user is redirected to the client with an `authorization code` in the request * The client sends the `authorization code` to the authorization server. * The authorization server generates an `access token` with the specific permissions that the client requested, expires the `authorization code`, and returns the `access token` to the client, * The client requests the protected resource from the resource server using the `access token`. * The resource server verifes that the `access token` is valid. If it is, it allows access .. note:: the `authorization code` is only good for retrieving a single `access token` for the particular set of permissions that the user confirmed. .. note:: A client can request access to multiple resources at once. Assuming the resource owner accepted all of them, the access token the client receives at the end will allow access to all of those. A client typically has one access token from an authorization server that grants it all needed permissions on all of the resource servers that the authorization server can give out permissions for. It is possible for a client to have multiple access tokens with different permissions from the same authorization server but the client would have to keep track of which permissions were granted by which token (and the user would have had to confirm that the client should be granted each set of permissions). .. question:: an access token can contain permissions for multiple resource servers. How do we secure the token from being used maliciously by a different resource server? ie: I get an access token which grants some permissions on both fas and bodhi. I send that access token to fas to retrieve some information. What prevents fas from hanging onto that token and using it to access the protected resources on bodhi that it grants without my knowledge? == But wait, there's more! == We've now seen one authorization via oauth. But Oauth is flexible. There's a few different ways this can work to be aware of: * Other ways to request the access token. The example above is what works best for third-party web clients. However, there's other flows that might work better for CLI apps or "trusted" web clients - Implicit: user gets the access token directly from the authorization server rather than through a authorization code. This sortcut is useful when the client is entirely in the browser (no third-party server involved). With a third party server, the authorization code makes it so the user never sees the actual access token, only the authorization code. if the client is running on the user's machine anyhow, there's no sense in that step. - Resource owner password credentials: The resource owner provides their credentials (username and password) to the client. The client retrieves the access token from the authorization server using the credentials. Then it discards the credentials and only keeps the access token for further requests. - Client credentials: Just defines that if the client is the resource server, it can authenticate itself to access its own resources... I'm a little unclear on this but I think one use would be for a resource server to use its externally available functions (which are protected by oauth) rather than having to write an equivalent function that is usable internally. puiterwijk mentions a different use: having a strict separation between tenants in the resource server's model and then having to prove you have permission to access the resource from a different tenant (not something we're likely to do). * Verification of the access token can take many forms. - The authorization server could notify the resource server whenever a new access token is issued/revoked - The resource server could ask the authorization server to verify the token each time it receives one - The token could be signed by the auth server and thus be verifiable in and of itself. The token could then contain the list of permissions so that the resource server would just consult the token to know what was available. This should not be preferred as it makes revoking a token harder. * The authorization server may or may not know about the range of permissions that it can grant. The resource server needs to interpret what the permissions the access token grants mean so if the authorization server grants a made-up permission the application should just ignore it. .. question:: Is it possible for the user to grant some of the requested permissions and deny others? Or is it all or nothing? == Refreshing a token and its caveats == An access token can have an expire time. The expire time can be coupled with a second token called a refresh token. Usually the refresh token would expire sometime after the access token would expire. When the access token expires, the refresh token could be used by the client to request a new access token without prompting the user. This is indended to protect against an attacker who is sniffing packets from amassing enough ciphertext from multiple uses of a single access token to be able to brute force that token. This sort of automatic expiration and refresh **is not** meant to protect the user in case the access token is copied without their knowledge (because the refresh token can be copied at the same time). = Part II: How do we use this? = This section is less about OAuth itself but some proposals about how we can best code OAuth usage in our web applications to be secure and featureful. == Session vs token == Currently we have a concept of a session in all of our web apps. You login. Once you're logged in, the web app knows that future connections from your web browser/CLI/etc are being made by you. At some point the session expires or you explicitly log out. At that point, the session is over. The expiration time for most of our apps is currently 20 minuts of idle time but we've talked about increasing this in the past. Sessions in my mind should last tens of minutes to hours. Certainly no more than a day. A session conceptually tells the server that the user is present and interacting with the website (by saying that the user has "recently" authenticated). Tokens are more akin to passwords coupled with a restricted set of permissions. They're intended to be valid for days to weeks. Refresh tokens can (but don't necessarily) be used to keep a low amount of ciphertext in the system while still making authentication via access token transparent to the client. Conceptually, they tell the server that the **client** (not user) is the same one that was granted the permissions. === Using tokens to implement sessions === * Sessions need to be short term -- expiration would need to be low (perhaps an hour). No possibility to refresh the token. If you need to continue, you have to re-send your username + password (+ otp?) * We want this specific token to represent that the user is present, not just that the client has been delegated permissions. * It would make sense for the token to give out all permissions that the user has (at least, on this resource server) because the user is present. Example token permission: "*@*" permissions token * If possible, saving this type of session token into a wallet/keyring would make sense as that would encrypt the on-disk representation. However, we'd also have to account for the fact that these services might not be present. * Suggested to have access tokens with validity of 5 minutes. refresh tokens of 20 minutes. This would approximate our current cookie-based idle timeout. .. question:: Can we also have a maximum number of refreshes or maximum time before the user has to reenter their credentials (username + password (+otp?)) == Some proposed best practices == * Oauth allows for very granular permissions. You could put a separate permission on each resource that a client can request. However, it doesn't require that you are granular or not because the application interprets the meaning of the permission. A lazy resource server could have a single permission that covered anything that can be performed on the server but this means that a stolen token can be used to do anything that that user could do on that resource server. We should attempt to identify common use cases and code separate permissions for them. ie: "building a package in a copr" would belong in a separate permission from "creating a new copr". * An access token should not be taken to represent the presence of the user. It means the user has delegated permission to perform this action to some "client". It is possible that the client is a command line app or an api and the user is interacting with it directly but it cannot be assunmed that this is the case. * Following from that, changing authentication methods, password, yubikey, security questions, etc should never be allowed via an access token. We want the user to be present to change these settings. * Tokens and sessions should not contain information about the authentication status. They should not contain what permissions are held or when the session expires. These are for the resource server and authorization server to determine. * Also following from that -- we should write things to allow for a session to be sufficient for allowing users to perform actions. access tokens describe a subset of the functions that the user themselves is allowed to perform. * Client side -- we want to have different permissions if the user is running the cli from the command line vs running the cli from a cron job. A user running from the cli could be said to have a session. IRC log (since this is all paraphrased and I could have misunderstood what puiterwijk meant): http://toshio.fedorapeople.org/puiterwijk-oauth.html -Toshio

5 10

Request for a HyperKitty instance for an early adopter (Arquillian)
by Dan Allen 12 Mar '13

12 Mar '13

The Arquillian project [1] would like to volunteer to be an early adopter of HyperKitty. We are looking to shift from forums to mailinglists, but not lose a user-friendly web frontend for folks just browsing for information. We're writing to this list because we think that Fedora and Arquillian share a common goal to see HyperKitty evolve. We can offer to hack on it and promote it if Fedora infrastructure would be willing to give us a space to run a public instance of it. (We're also Fedora users, of course). We know about mm3test.fedoraproject.org, but we're hoping to be able to point discuss.arquillian.org at to the installation (CNAME support). We plan to actively work on HyperKitty to improve the functionality and user experience. Therefore, we'd like to request a dedicated instance to give us the flexibility to experiment as much as needed without having to worry about disrupting the other lists running on it. In other words, we want to be bleeding edge for a while :) Let us know whether this seems like a good fit. Although we are separate communities, I think the common goal of moving HyperKitty forward gives us good reason to work together. Plus, we're really eager to see HyperKitty get used for Fedora lists too. -Dan p.s. http://arquillian.org -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://google.com/profiles/dan.j.allen http://mojavelinux.com http://mojavelinux.com/seaminaction

2 2

Meeting Agenda Item: Introduction Qingwei Zhang.
by Qingwei Zhang 11 Mar '13

11 Mar '13

Dear All, This is Qingwei Zhang, a Computer Engineering Master's student from University of Ottawa, Canada. I am so happy that I can contribute to the team, and here is my introduction to the team. Name: Qingwei Zhang Time Zone / Country: UTC-5(Ottawa, Ontario, Canada.) Basic skills and experiences: 1. Intermediate C++, C, sed scripting, Makeﬁles 2. Professional: Shell script, Bash 3. Tools: Eclipse CDT, GDB, GNU Make, Vim, I have LPIC-1, and more than two years experience of Linux administration, and I have my own testing machines. Why you're joining: Two reasons, firstly, I like fedora, and want to do something for this project; secondly, this experiences can strengthen my skills as software developer. How much time you can contribute (usually hours per week): about 5 hours per week. Your IRC handle: #qzhan054 What you would like to work on and quite possibly which outstanding issues you would like to help resolve: I would like to learn how to create and maintain custom tools and applications to Automate Systems Maintenance. Currently, I think I can help with this problem: ticket #3701 (new task) Update Fedora Product Description in Bugzilla (Branch Day). Regarding my capacities, I am graduating in uOttawa with distinction in computer engineering. I am well versed in Linux administration, shell programing and computer C language. I came successful in all projects in the last year of the course. I am a self trained man with willingness to work for the welfare of the organization I am working, to the utmost satisfaction of my superiors. I also am a man of strict discipline and self restricted policies of sticking to punctuality, dedication in work, integrity and cooperation with other colleagues. Now I am ready work with the Fedora Infrastructure team at any time. I am looking forward to hearing from you soon! Thank you. Qingwei Zhang. -- Qingwei Zhang Do something today that your future self will thank you for.

1 0

Jenkins update
by Pierre-Yves Chibon 08 Mar '13

08 Mar '13

Hi all, I have written this last week-end and I'm late... I have started to write down some instruction on how one can get his/her project added to our jenkins server: https://fedoraproject.org/wiki/Jenkins@infra And (attached) I wrote a small SOP on how we should handle this. These two documents are up for review, discussion and correction. Please fire away :) Thanks, Pierre

3 5

vfad - virtual fedora activity day ideas
by Seth Vidal 07 Mar '13

07 Mar '13

Hi, We discussed this today in the infra meeting: We've had some success with FADs - fedora activity days - most recently for 2-factor-auth. FADs let us focus on a specific task and knock it out by having all the stakeholders together in one place and all ready to only do achieve one goal. The problem is they require people all come to one location and we have hotels to put people in, etc. Which is not only expensive but a giant pain in the ass. :) I'd like for us to try out a VFAD where we act like we are in a FAD but we don't go anywhere. We come together in a single irc channel. We tune out our other msging channels. We all gather on a single google hangout or conference call so we can just yell at each other when needed. In short we use all the high-bandwidth things we can to provide access to each other but from remote locations. so we discussed ideas of what to do on such days and a lot of ideas came out of it (in no particular order) - application logging/logging in general - enhancing our trending/analysis - making our web app logging not be so much pain - making sure our logs are complete and legible - 2fa in apps - making all of our apps use 2fa if available - app/appserver break out - breaking our apps from grouped app## servers into individual application instance (tagger##, bodhi##, etc) - helps with isolating where problems actually live - ansible migration - cli logins for web apps - dealing with our decisions on tokens or oauth, etc and implementing it - fedorahosted-ng - the next iteration of fedorahosted and what we need to add to make it fast/better/great - IDS - intrusion detection - db-replication/SPOF-removal - right now our db servers are our major single-point-of-failure - replicate our db servers - better failover conditions - nagios - automating more of nagios - handling errors better - cloud-productionizing - things to make our cloud fully production Other ideas? Please let us know what you think and add ideas. -sv

1 0

Plan for tomorrow's Fedora Infrastructure meeting (2013-03-07)
by Kevin Fenzi 07 Mar '13

07 Mar '13

The infrastructure team will be having it's weekly meeting tomorrow, 2013-03-07 at 19:00 UTC in #fedora-meeting on the freenode network. Suggested topics: #topic New folks introductions and Apprentice tasks. If any new folks want to give a quick one line bio or any apprentices would like to ask general questions, they can do so in this part of the meeting. Don't be shy! #topic Applications status / discussion Check in on status of our applications: pkgdb, fas, bodhi, koji, community, voting, tagger, packager, dpsearch, etc. If there's new releases, bugs we need to work around or things to note. #topic Sysadmin status / discussion Here we talk about sysadmin related happenings from the previous week, or things that are upcoming. #topic Private Cloud status update / discussion #topic Upcoming Tasks/Items #info 2013-03-07 remove inactive apprentices. #info 2013-03-12 to 2013-03-21 pycon #info 2013-03-19 to 2013-03-26 - koji update #info 2013-03-29 - spring holiday. #info 2013-04-02 to 2013-04-16 ALPHA infrastructure freeze #info 2013-04-16 F19 alpha release #info 2013-05-07 to 2013-05-21 BETA infrastructure freeze #info 2013-05-21 F19 beta release #info 2013-05-31 end of 1st quarter #info 2013-06-11 to 2013-06-25 FINAL infrastructure freeze. #info 2013-06-25 F19 FINAL release #topic Open Floor Submit your agenda items, as tickets in the trac instance and send a note replying to this thread. More info here: https://fedoraproject.org/wiki/Infrastructure/Meetings#Meetings Thanks kevin

1 1

Introduction
by Alexander Rudolf 06 Mar '13

06 Mar '13

Hi folks, I would like to introduce myself too: First of all I would like to give a "thanks a lot" and "wow - great job!!!" to all who have made fedora become reality!!! It is fun to work with it. My name is Alexander Rudolf. I live in Germany. I am an IT infrastructure consultant and systems engineer working for a company in Dresden, Saxony. "Growed up" (I am 39) with MS-DOS an Novell NetWare in the early 90s when I started my work live I now have a lot experience with heterogeneous networks, network equipment and security, systems management, high availability solutions and those things. Made my MCSA for Windows Server and am LPI-C certified since 2006. My most recent experiences are in Linux system administration, security, virtualization and most of all - Nagios. I supported a number of related projects for some customers and wrote a couple of Nagios plugins. Most of them in bash, but also in VBS and PowerShell for the windows driven landscape. I would now like to actively join the fedora infrastructure team and do my very best to provide support. Please help me to understand how I can contribute best! Best regards, Alex

2 2

Re: New Fedora openid provider (fas-openid) in service
by Rahul Sundaram 05 Mar '13

05 Mar '13

On 03/05/2013 07:19 PM, Kevin Fenzi wrote: > Code for this provider (under GPLv2+) is available at: > > https://github.com/fedora-infra/fas-openid Congrats! I was wondering if we have relaxed the infrastructure policy of not relying on web infrastructure that depends on proprietary code? Rahul

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

infrastructure March 2013