IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
None of these rules is supposed to be changed by users, so move
them out of /etc. Custom rules, and automatically generated rules
stay in /etc. All rules are still processed in lexical order,
regardless which directory they live in.
Fix an error message displayed by write_net_rules when the rules file
does not exist yet. (See Debian bugs #442796 and #475699.)
Ignore commented rules, at least for the easy case.
For clarity, use extended instead of standard regular expressions.
Some boxes, like the PS3, have multiple independent hardware
interfaces, all sharing the same MAC address. If they have
different interface names base names, we can distinguish them
that way.
Thanks to Alexander E. Patrakov for pointing out that we create
invalid rules.
We still need a proper fix for devices we skip creating rules
(locally administered MAC), but want to swap names with interface
names we created rules for.
The argument to find_all_rules must be quoted or it will be subject to
shell expansion, which will happen if in the root directory there are
mount points with the same base name.
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407738 for details.
The decision about when to create by-id or by-path persistent rules should
be made in the generator rules file where it's obvious and easy to modify
locally, not in the script.
This should be called by triggering events not by looping with
the script itself. It also keeps a second blacklist outside of
the rules which we do not want to maintain.
Bryan Kadzban wrote:
> Marco d'Itri wrote:
> > Bryan Kadzban wrote:
> >
> > > This is a sort of follow-up of my path-based persistence patch for
> > > net devices; it's the opposite type of addition for CD symlinks.
> >
> > Looks good. I am attaching a slightly reformatted version, I think it
> > should be applied.
>
> That's probably a lot more clear than my version anyway: what you posted
> looks like it does basically the same thing, just with some changes in
> the order and sense of checks.
