Verifying a FAS instance via JSON?
by Paul W. Frields
This is probably going to be a very naive question, so bear with me.
I'm trying my hand at an AuthFAS plugin for Drupal. As part of that
code, I'm trying to verify the setting of a FAS instance URL, by using
curl to hit https://<URL>/json/ (like
https://admin.fedoraproject.org/accounts/json/). I give the
administrator an opportunity to enter FAS credentials to be used in
the curl process.
The code is found here (in the authfas_admin_validate() function):
http://fedorapeople.org/gitweb?p=pfrields/public_git/drupal-authfas-6x.gi...
If I'm at a browser and I hit https://admin.fp.o/accounts/json/
directly, I have to enter my username/passphrase, and then I get a
JSON result that includes a 'help' element, which is what I'm checking
for in the code. This is sort of an optional step, really. I wanted to
make it possible for people to know if they made a typo in the URL.
But if I have to drop that validation step, and simply depend on the
admin to get it right, that's probably acceptable. Maybe I'm trying to
be too clever.
In any case, regardless of the username and password I use, I don't
get back a positive result. It's possible that's because I'm getting a
login or some sort of CSRF intermediary request. I confess I haven't
had a ton of time to dig deeply into the problem. I was hoping someone
here would be able to say, "Here's something you need to do if you're
using curl like that...". The curl code here is drawn from the
original Auth_FAS.php on the wiki, but I'm not sure if the changes I
made are all kosher.
Any help appreciated!
--
Paul
13 years, 10 months
Looking for input: Segregating hosts to specific VM servers
by Stephen John Smoogen
Currently we have our staging environment and our production
environment on the same servers. This works well for the most part
because the loads generated by staging rarely affect production.
However there are times where it would be nice to be able to test
certain 'issues' together. As in updating the core xen/kvm server and
a staging environment without affecting anything in production. My
idea would be to look at either repurposing or budgeting for a staging
xen server (lets call it sxen01 for convention) that would be used for
various staging servers that could test for updates to say EL5.5->
EL5.6 on all the systems at once or to work on tuning variables
without affecting production servers.
This is an initial idea so I am looking for feedback.
Thanks.
--
Stephen J Smoogen.
“The core skill of innovators is error recovery, not failure avoidance.”
Randy Nelson, President of Pixar University.
"We have a strategic plan. It's called doing things.""
— Herb Kelleher, founder Southwest Airlines
13 years, 10 months
Introducing myself
by Devin Ryan
Hello,
My name is Devin (I go by the alias of SkynetLabs). I've decided it's time
to introduce myself. I have about 3-4 years of sysadmin experience with
servers in general, and about 2-3 years with *NIX servers (even if I don't
know a lot, I'm willing and hoping to learn more in my time as a
contributor). I currently live in Illinois in the USA, and I'm looking
forward to helping Fedora soon.
--
-Devin Ryan (skynetlabs)
13 years, 10 months
Questions about fedorahosted features and plans
by jason.guiditta
Hello, my group has been using fedorahosted for a couple projects for at
least a year now, very happy that this service exists - and the folks in
#fedora-admin are always friendly and helpful. Given our use of this
service, I was curious about a couple things. First, obviously gitorious
and github are the two main alternatives for (git) project hosting. While
github does not publish the source that powers their app, they do have a
number of nice features and services, and I was wondering if there were any
plans to try to replicate any of these things.
Some examples of what I mean include web hooks (
http://help.github.com/testing-webhooks/), pre-rolled post-commit hooks
(IRC, Jabber, Email, Trac, Campfire, etc.), gist (I know fedora has fpaste,
but gist has permanent option, and it is version controlled as well), and
general end-user-friendly things like a 'fork' button and useful docs/help (
http://develop.github.com/ and http://help.github.com/ for example).
Anyway, while it is not as open as fedorahosted, it does have a lot of nice
features, just wondering if this was being looked at as possible things to
reimplement or emulate on the fh side?
Related, kind of - is there a roadmap page on the wiki somewhere? Also, are
there any docs on what supported git hooks there are on fh?
-j
13 years, 10 months
Infrastructure Updates for 2010-07
by Stephen John Smoogen
= Reasons for Updates =
In the previous month there have been multiple updates for security
and functionality. The major ones affecting all systems have been
updates to xen and kernel-xen. These will require a reboot of all
systems.
= How will this be accomplished =
* 2010-07-13 update of publictest and staging servers.
* 2010-07-14 testing of applications/problems
* 2010-07-15 update of production servers and reboot of all servers.
As always production development systems will be dealt with by Dennis
Gilmore to make sure that problems do not impact builds.
= Steps to remember =
* Announce what servers are being updated at what time.
* Make sure noc01 and noc02 have temporarily stopped monitoring things.
* Update servers or report problems to #fedora-noc
* NEVER use --force or --nodeps to install an update. If its not
working find and diagnose why its not working.
* Give at least 30 seconds notice on #fedora-noc before rebooting a
system(s). This allows for people to say "STOP" or other words.
* Certain servers need to be booted in certain orders. (Make sure
that both bastion hosts are not being rebooted at the same time).
* When systems are up and tested good, make sure noc01/noc02 are
aware of the systems again.
= Known Updates for 2010-07 =
== Security Updates ==
https://rhn.redhat.com/errata/RHSA-2010-0504.html
https://rhn.redhat.com/errata/RHSA-2010-0475.html
= BugFix Updates =
https://rhn.redhat.com/errata/RHBA-2010-0515.html
https://rhn.redhat.com/errata/RHBA-2010-0510.html
https://rhn.redhat.com/errata/RHBA-2010-0513.html
https://rhn.redhat.com/errata/RHBA-2010-0509.html
https://rhn.redhat.com/errata/RHBA-2010-0517.html
= EPEL packages =
rkhunter
collectd
nagios
koji
--
Stephen J Smoogen.
“The core skill of innovators is error recovery, not failure avoidance.”
Randy Nelson, President of Pixar University.
"We have a strategic plan. It's called doing things.""
— Herb Kelleher, founder Southwest Airlines
13 years, 10 months
Puppet checks in nagios
by Todd Zullinger
While Ricky E. was working on some improved lockfile checks, I
mentioned having done some checks on the puppetdlock file where I work
that allow us to drop some text into that file giving a reason why
puppet is disabled. It also lets nagios read that content and display
it, making it easier to tell when a box has puppet intentionally
disabled (changing what would be a CRIT for not running in N seconds
into a WARN).
Mike asked me to post this code here (again, in case I did it before).
So, the mildly over-engineered check_puppet and puppetstatus tools are
at: http://tmz.fedorapeople.org/scripts/puppetstatus/
Here's a brief description I wrote on this to the puppet list when
nagios checks came up a little while ago¹:
I have found it necessary to disable puppet for a short time to work
on something and not have puppet helpfully undo my work more than a
few times. While it's easy to use puppetd --disable to prevent puppet
from running, it's also easy to forget to re-enable it. Or worse, in
a place with multiple SA's, it's easy for someone else to come along
and notice puppetd seems to be 'stuck' and 'helpfully' clear out the
lock file.
Using 'sudo puppetstatus -d "Testing some foo"' creates the lock file
as puppetd --disable would, but adds the text given and the username
of the person disabling puppet. That then shows up in nagios and if
puppet remains disabled for longer than check_puppet would normally
consider a critical amount of time, it remains a warning if there is a
reason in the lockfile. That also lets other SA's know puppet is down
intentionally so they don't have to bug me or worry about 'fixing' it.
(The checks in the script to chide folks running it as root are more
of a goof, to gently prod admins in the habit of doing everything as
root to stop that. :)
¹ http://groups.google.com/group/puppet-users/browse_thread/thread/ab9cb64b...
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Genius is 1% inspiration and 99% perspiration, which is why engineers
sometimes smell really bad.
-- Demotivators (www.despair.com)
13 years, 10 months
func commands
by Seth Vidal
Hey folks,
I added some of the func-scriptlets I'd written up into puppet and got
them installed on puppet1 in /usr/local/bin/
the commands are:
func-command: run a shell command on whatever boxes you want - output
comes back nicely
func-grep: run grep just like you normally would but return results from
any/all machines. hostname:filename:matchedline
func-down-hosts: return the func/puppet hosts which are not responding
to func or to the network :(
func-find-user: return processes owned by that user on any/all hosts
func-whatsmyname: return func hosts where the func/puppet name and the
systems hostname doesn't match up
func-list-vms-per-host: list vms owned per host
all of these commands take these options:
--host=hostname_or_glob - you can specify --host multiple times
--forks=int - number of forks to spin off to make the command complete -
defaults to 40 in most cases which is plenty
--timeout=int - length of time to wait for a response from the
system/process - the defaults in the scripts are pretty good but you
should adjust them as you see fit, of course
all of these require root/sudo access on puppet1 to run - the next stage
in things is for me to make it so we can do it by specific certs/per
user. The code exists - I just need to get it deployed w/the acls to
the clients.
thanks,
-sv
13 years, 10 months
