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.
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.
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
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)
- 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
- rsync it out
- 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
- 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
(This is ignoring the process of rsyncing to the mirror master, which
will be gross.)
I wrote a script to auto-generate the .html page at
torrent.fedoraproject.org and the rss feed as well. I also documented
the steps necessary to release a torrent. It's pretty straightforward
but if you have any questions/suggestions yell at me, please.
A couple of questions:
1. where should I link that page from?
2. is there a better page for docs for infrastructure in general?
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
Please vote for your favorite choice at:
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
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 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:
> 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, 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
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.
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 ?
File "./report_mirror", line 236, in main
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
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
File "/usr/lib/python2.4/xmlrpclib.py", line 744, in close
xmlrpclib.Fault: <Fault 1: "'NoneType' object has no attribute
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.
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!