thanks,
jat
> I see that WAN replica isn't supported on Linux.
No idea what you mean by this; you certainly can put a Linux server in a
remote site and host a replica of a partition on that as part of a tree,
as long as the networks are connected networks and not NATted networks.
Can you clarify what it is that you mean by the above statement?
Jim
--
Jim Henderson, CNA6, CDE, CNI, LPIC-1
Novell Training Services
I got this from the link (look at the bottom the page). Should I be
concerned about WAN replica info? It isn't a very dynamic directory (not
alot of changes) and there's about 150+ users on the remote site.
Sorry on the link, click on the "WAN Traffic Manger" link once in here:
WAN Traffic Manager is basically a generic proxy and filter that you put
on a machine that's a bottleneck for a WAN connection. It's somewhat
obsolete since you can basically do the same thing with iptables or any
Cisco router.
--
Justin Grote
Network Architect
JWG Networks
> Should I be
> concerned about WAN replica info? It isn't a very dynamic directory (not
> alot of changes) and there's about 150+ users on the remote site.
Nope, nothing to be concerned about here - this is the sort of thing eDir
is designed to handle. :-)
> Sorry on the link, click on the "WAN Traffic Manger" link once in here:
I see now where the confusion lies.
WTM is a component used very rarely (typically for expensive on-demand
links that you don't want up all the time); that it is not available on
Linux does not imply you cannot place remote replicas of partitions over
a WAN, just that with Linux there is no WTM so you can't use it to prevent
those type of on-demand links from coming up when eDir goes to sync.
Those of us using news readers that do not have three and a half (!!)
years of history cannot see the rest of the thread, so it may be useful
next time to just start a new one. Still, since you've gone through the
effort....
Sure, you can block both outbound and inbound traffic with iptables simply
enough. How you would make it work within a certain time period without
having a cron job enable/disable periodically is not something I can
answer, but a cron job to do that would be easy enough. With that said
this will cause nastygrams in iMonitor or ndsrepair whenever your
replication time is outside of its one-hour limit. Using a remote replica
for high availability is one of the primary purposes of multiple replicas
but I am not clear why you would want to do this for just a couple hours
per day. Why not, instead, just get a backup of your server using
something like ndsrc.pl (CoolSolution, not supported, but it works well)
or dsbk (documented, supported, replica-aware)? Having cron run that
daily is also trivial.
Good luck.
fevans wrote:
> Bringing back an old post, but I have a question about this comment.
> Iptables and Cisco Routers can limit traffic which is part of what WTM
> offers, but what about the scheduled synchronization? I was liking the
> feature that allowed us to synchronize only between 1am and 3am as
> another backup option for eDirectory. Is this also a feature that can
> be implemented using IP related technologies instead of WTM.
>
> Note: our solution is all on Linux and since WTM is not supported on
> Linux I am looking for other solutions.
>
> ~F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJLJ+JWAAoJEF+XTK08PnB5ZmcQAM8COytOjMJbWdmRRagYxfeC
8GFvGJjYnxEIrRXSXQwbjU0sZ44HDdiFsQlKdIjEAfUz+B30+LmEtxWJ1LhK95Dc
e3SmFkbs41OGEVPO8Tf/8GeHQDgA0uMYKHp3lhPH3niccp7ogrOK+jbtui+svIB/
NjFCEfh/XW8iU327FNAl1S/honCIUmZc6wmVvE/hyWbIbmKq6jVHrcVabL1DA1fL
eUVh4nxUZTVLBYthXYKufwzE8VNrsOzstkEeoWpBc+ZKUy/B82bXcWxKDGA7hhNm
xRldz/zbbV9gsouKilR9GWwIs/NF2X/G3XJYEv5QSDsydIdJXo3PJQQdwcw2OXvj
Bsxq9sofSCNW9U05YYWTyRi0aS6n5cBm/ixX/CjSWxbKdI09yG012AWsVbCHTPYD
AoLlEbPjFMr1GAcH4z0m9AgPibwrUDvk4wNc64zte8XwdZ/ng8a5DdzN8IIx0pfB
8XcgNUgQCpvBG4Qt0J1Ak6l1GeiNQo7gyzL5aNn5WvxTTpbS4RE7ygSyNdH+aw6B
HDFoAIBOZgi0emcqaSeg/dlmuaRStj7k8I1DHJmnPvCTPmGEwmtF/Tzu5kESVgH+
/MYi2eWmx+3bJB8PPjjUsiquImEy+vc3X9ThZ5G2WJePxFEU6aQUGA0VXsHeuSKw
Ku7KK3jHfh/yonNedCms
=C9R3
-----END PGP SIGNATURE-----