iptables templates
by Seth Vidal
Here's what I've used in the past.
It allows connections for certain ports/places and then drops everything
else as the last item.
http://linux.duke.edu/~skvidal/misc/iptables-template
it's pretty painless, really.
If we want to add explicit outbound rules, too, that's fine, but I'd
advise enabling logging b/c that stuff is easy to get wrong. :)
This is just a sample but it's simple and straightforward.
-sv
16 years, 11 months
denyhosts on publictest boxes
by Dennis Gilmore
Hey all,
Just a quick reminder that all public facing boxes need denyhosts installed
and running on them. epylog showed
36.subnet222-124-137.astinet.telkom.net.id failed to log in as root 121 times
yesterday. they are obviously someone we dont want logging into anything
Dennis
16 years, 11 months
the mechanics of pushing updates
by Bill Nottingham
Mmm, plumbing. bodhi is heading for production soon. To push updates, what
bodhi currently does is, for any update:
- sign the package
- copy the package to a 'staging' tree of the entirety of updates
- read a static list of packages that should be multilib, act on that
- run createrepo
- check deps on the repo
- rsync the whole repo out
Older updates are cleaned by a cron script later.
Advantages of this approach:
- it's simple
- it's easy to clean upthings that Go Wrong (just manually remove them
from the repo and re-sync)
Disadvantages:
- multilib. In a world where we continually add new packages, this
*will not scale*.
So, we need at least *some* sort of better workflow.
One alternative - using mash (what we're using to build rawhide.) It
would go something like this:
- sign the package
- tag the package (for updates-testing, or updates)
- run mash to create a repo of updates/updates-testing, solve it for
multilib
- rsync it out
Advantages:
- solves multilib
- doesn't require continually keeping a staging tree around
- depcheck is built in when solving multilib
- builds on koji tags to let anyone easily query what updates are
released
Disadvantages:
- by rebuilding the repo each time, it's going to be slow once
the repo gets large
- harder to clear out other strangeness
- will only have one version of each updated package
The last of these isn't as *big* of a concern now, as all builds
will be available through the koji web site, space permitting.
Other ideas for better workflow? What do the extras push scripts do?
Do we want to add a modified version of mash's multilib solver into
bodhi?
(This is ignoring the process of rsyncing to the mirror master, which
will be gross.)
Bill
16 years, 11 months
http://fedoraproject.org/PackageReviewStatus
by Toshio Kuratomi
I've made some changes to the scripts behind PackageReviewStatus that
should make it a bit more robust in the face of errors. Feel free to
ping me if any problems crop up.
-Toshio
16 years, 11 months
Vote for the (probable) name of Fedora 7!
by Bill Nottingham
The board has sent a list of suggested names for Fedora 7 to our legal
department, and they have responded with the names that have passed preliminary
legal approval.
Please vote for your favorite choice at:
https://admin.fedoraproject.org/voting/vote.cgi
The choices are 'Lee', 'Sherman', 'Nothing', 'Cylon', 'Moonshine', 'Siegfried'.
You will need to log in with your Fedora account system user/password. Voting
will be open until 2007-05-25 00:00:00 UTC. Thanks to Toshio Kuratomi for
getting this set up.
We apologize for the short voting timeframe - final legal approval can take
up to five days, and we'd really like to avoid slipping solely for the name
of the release. If there end up being legal issues with the name selected, the
Board will decide on the name. (Who knows, could end up being Zod 2: Electric
Zod-a-loo).
Bill
16 years, 11 months
Re: Security concerns with mirrormanager
by Dax Kelson
On Tue, 2007-05-22 at 22:45 -0500, Matt Domsch wrote:
> On Tue, May 22, 2007 at 05:58:03PM -0600, Dax Kelson wrote:
> > I mentioned on the list a few months back a technique for having YUM
> > automatically use a local mirror without any configuration changes on
> > the clients. A few people sent me emails asking for more details, so I
> > was goaded/spurred into implementing it and have now documented the
> > procedure in a new GURU GUIDE.
>
> Dax, very cool. Thanks for posting this.
>
> One thing I added to mirrormanager[1] was the ability for a mirror
> host to specify the set of IP netblocks that should use the local
> mirror. When a yum client hits the mirrorlist CGI, such as:
>
> http://mirrors.fedoraproject.org/mirrorlist?repo=core-6&arch=i386
>
> it looks up the client IP address in mirrormanager's database. If one
> or more of the hosts in that database claim that IP address as "local"
> to them, the CGI returns just those hosts.
>
> In mirrormanager, you can have private mirror sites and private mirror
> hosts, so they never appear on the public list of servers, but the
> mirrorlist CGI can still handle them. The drawback is that
> mirrormanager can't crawl private mirror sites (generally). So, you
> have to use mirrormanager's report_mirror script[2], which runs on your
> private mirror, to tell the mirrormanager database what content you
> have. With this little bit of setup, you can get much the same
> benefit as your setup provides.
Matt, mirrormanager is very cool!
For YUM to automatically find a mirror I believe the cleanest and best
solution is have it be done within Yum itself. Possibly with a WPAD-like
or DNS SRV technique. It should be on default.
The idea of the main mirrorlist CGI having a database of local IPs and
mirrors is actually a solution that I ran through mentally awhile back
and came to the conclusion that security concerns and technical
limitations made it unworkable.
When you attach your computer to a network there is some level of
implicit trust in the local network (and whoever manages it). But this
is a two party relationship and doesn't involve a third party who is a
random stranger on the internet.
The main security concern I have with the DB of local IPs, is what is to
prevent someone from listing my IP network as local to their mirror?
This could be accidental via a netmask typo, or with a more sinister
intent (cross your fingers that your users pay attention to gpg messages
from yum).
IMHO, this should not be possible. If mirrormanager intends to maintain
a DB of local IPs for a mirror, then the ownership/control of the IP
range *must* be strongly authenticated. It should be done securely, or
not at all.
Different people have different security requirements, but I believe
that some people will be in for a shock and react poorly/predictably
when they find out that their IP netblocks (or any portion thereof)
could be redirected.
The technical limitation of the DB of local IPs is that it doesn't work
for organizations who run their mirrors on a RFC1918 IP and use NAT to
get out to the internet. This scenario is very common.
Dax Kelson
Guru Labs
16 years, 11 months
report_mirror traceback
by Chuck Anderson
I'm getting a traceback running report_mirror on my FC6 mirror system:
$ ./report_mirror -o mirror-report.txt -c report_mirror.conf
Traceback (most recent call last):
File "./report_mirror", line 240, in ?
main()
File "./report_mirror", line 236, in main
print server.checkin(base64.urlsafe_b64encode(bz2.compress(p)))
File "/usr/lib/python2.4/xmlrpclib.py", line 1096, in __call__
return self.__send(self.__name, args)
File "/usr/lib/python2.4/xmlrpclib.py", line 1383, in __request
verbose=self.__verbose
File "/usr/lib/python2.4/xmlrpclib.py", line 1147, in request
return self._parse_response(h.getfile(), sock)
File "/usr/lib/python2.4/xmlrpclib.py", line 1286, in
_parse_response
return u.close()
File "/usr/lib/python2.4/xmlrpclib.py", line 744, in close
raise Fault(**self._stack[0])
xmlrpclib.Fault: <Fault 1: "'NoneType' object has no attribute
'keys'">
16 years, 11 months
Image standards
by Mike McGrath
Anyone have a problem with us using SVG for image sources and PNG for
final copies on our websites? We can grandfather this in but mizmo
suggested it on the websites-list. I think its a good idea.
-Mike
16 years, 11 months
Participation
by Freddie Rosario
Hey to all,
My name is Freddie and I am looking to get involved in Fedora in some way. I
browsed the website and saw that Fedora is looking for people who have some
experience with Linux and Python in general. I would like to donate about an
hour every night or every other night. Does anyone need any help with a
project? I currently work for Google and have some experience with somewhat
large networks and computing environments. I want to start small and work my
way up. Even though I work for Google, I do not want to give the impression
that I know everything. I am here to learn and help out where I can. Thank
you for your time!
--Freddie
16 years, 11 months
