Hi everybody! Those of you that have problems keeping in sync with the Factory distribution using the drpmsync client might be interested in a tool I hacked because I had problems as well. Note that this tool definitely has some bugs left but for me it is currently the only chance to sync the tree because the drpmsync server is that slow that it cannot serve the standard drpmsync client fast enough to ever get a consistent sync. Because I have not yet implemented all cleanup code it might be useful to run the standard drpmsync client once after the sync is complete with my tool but even if you don't do so the resulting repository should still be usable with YaST or other tools. Still interested? You can find the tool along with a sample config file in http://pi3.informatik.uni-mannheim.de/~schiele/mydrpmsync/. Although there is no license specified in the files consider the tool to be published under the same license than the drpmsync client from the deltarpm package. Note that although the default rsync server in the tool is ftp4.gwdg.de you can no longer use this server for this purpose because Eberhard does no longer sync the delta files. Note as well that you need the lockfile binary from the procmail package in your path for this script to work. A standard SUSE installation should already fulfill this requirement. You can speed up the sync by specifying multiple rsync servers in a useful order. A useful order is specifying the fastest servers first and the most accurate (in sync) last. It does not make sense to specify a server if you have another one specified that is faster and more accurate. You shouldn't overdo with the number of servers because this might even slow down the tool. It's the same with the other parameters. Often it is useful to play a bit with them to find the most setup with most performance for your system. Questions and comments are always welcome! NOTE: The tool is still in the quick-hack-state. It does _not_ handle all errors correctly and has some known security flaws. Thus only use it if you fully trust the operators of _all_ servers you specify in the config or if you are running the script in an environment that is not of any importance to you. Though problems that are not injected on purpose should not destroy anything on your system but there is absolutely no warranty. Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:rschiele@uni-mannheim.de
participants (1)
-
Robert Schiele