Re: Rad conf option
> I think this could be beneficial in term of conf' simplicity and avoiding > mistakes (especially if the router has to deal with frequent renumbering). about frequent configuration changes(when the prefix is assigned dynamically)- a hook is needed(you will need a client who can do it) or a task in cron to track a prefix change, and in the handler of this event you change rad.conf accordingly and send SIGHUP to rad(i checked- rad is able to re-read the configuration file. why is this not mentioned in man? %\). you want rad to stick his nose in other business, make assumptions that he has no right to(how for example miniupnpd does it >:()
upnp/ssdp
maybe at some future hackathon, instead of blackjack and whores, get a time for question about that we don't have a sane upnp demon? ;) because the problem of switching to ipv6 will last at least another twenty-five years. i don't think that everything needs to be implemented here, personally, the part that is responsible for port forwarding and igd device detection is enough for me(and probably for most people). of course, there is no point in doing anything in the next year or two, since a nuclear war may happen and then we won't need anything :\
Re: Rad conf option
> Hello
> I think the "nameserver" option of rad (router advertisement daemon) should
> be
> able to support a keyword like "self" to refer the router itself as a
> nameserver also, similar to the "self" keyword in PF.
> This could be a reference in the global configuration and/or specific
> interfaces
> conf'.
> I think this could be beneficial in term of conf' simplicity and avoiding
> mistakes (especially if the router has to deal with frequent renumbering).
> example :
> Currently:
> interface re0
> dns {
> nameserver 2a06:a4:7d:20::1 2600::1
> }
> interface re1
> dns {
> nameserver 2a06:a4:7d:30::1
> }
> ---
> wish:
> dns {
>nameserver self
> }
> interface re0
> interface re1
just keep in mind that "self" can be not one address, but several. for example,
i have four(1 ipv4 + 3 ipv6) of them- will they all be available to the client?
/var in ram
hi guys. how to move /var to ram correctly? what i do: i run nfs and mountd(and portmap, without it does not work), then i mount /var via mountd to some place, for example in /mnt/var (here i have to say "thanks" to the dude who sawed out LKM, you all know his name). via mount_mfs i replace /var on disk with /var in ram, all this i writing in fstab. then i put openrsync in cron for synchronization /var in ram to original /var in /mnt/var. i also put openrsync in rc.shutdown in order to synchronize on shutdown (i can't use syncthing because in a critical task for the life of the system you can use only what is already in the system). finally, i edit /etc/rc and replace "mount -a -t nonfs,vnd" with "mount -a -t nonfs,vnd,mfs"(to be honest, i do not know what i am doing, but it works), otherwise when the system boots not everything from /var on disk is copied to /var in ram. the first problem is that after a while, without any declaration of war, the system stops responding to anything. no, she's not crashing. so i do not know what exactly is going on, there is nothing interesting in the log. the second problem is that the use of openrsync leads to the fact that mbufs grow by a thousand at once, and do not return back. and plus a thousand is not the limit, and maybe this is the reason that the system hangs. the third problem is that when the system is shutdowning, openrsync starts its dark deeds, but suddenly something kills him (i have some vague memories that this can be prevented somehow). in general, it doesn't look like my path is right. what is the right way? ps: and i also have a terrible feeling of deja vu. it was be somewhere before? i was looking for a match, but, unfortunately, most of my archive is lost, and google is no longer the same as before
