 |  |
https://bugtraq.ru/dnet/faq/client/ |
|
|||
|
|
|
||
| https://bugtraq.ru/dnet/faq/client/ |
||||
| ||||
Информация о клиентской программе distributed.net, устанавливаемой на машинах участников.
Установка, конфигурация и массовая установка
- Существует ли базовое руководство по установке клиента?
- Как запустить клиента?
- Как удалить клиента из системы?
- Как запустить Windows-клиента с иконкой в трее?
- Автоматический запуск клиента при загрузке системы
- Какие параметры командной строки поддерживает клиент?
- Можно ли сконфигурировать несколько клиентов/машин, использующих один и тот же идентификатор dnet(почтовый адрес)?
- Как заставить клиент использовать все процессоры на многопроцессорных системах?
- Как автоматически установить/обновить клиента на нескольких машинах, входящих в локальную сеть?
- Как задать разные настройки для клиентов, запускаемых с разделенного сетевого диска?
Общие вопросы по взаимодействию клиента с сервером
- Существует ли базовое руководство по взаимодействию клиента с сервером?
- Что, если я нахожусь за межсетевым экраном?
- Как заставить клиент осуществлять запуск/остановку/передачу блоков и т.п. по расписанию?
- Почему я получаю сетевые ошибки, или ошибки с распознаванием имен хостов?
- Как подключить к работе компьютер, не имеющий сетевого подключения?
- Можно ли получить/отправлять даныне по электронной почте?
- Можно ли организовать совместный доступ по сети к файлам с заданием?
- Я сконфигурировал клиента так, чтобы он использовал блоки определенного размера, но заметил, что иногда забираются блоки меньших размеров.
Модемное соединение
- Клиент пытается запустить автодозвон, но это ему не удается из-за того, что требуется пароль.
- Я использую модем. Как заставить клиента скачивать достаточное количество пакетов?
- Клиент пытается дозвониться слишком часто, или не прерывает связь.
- Как забирать достаточный объем данных для оффлайновой работы?
Общие стартовые вопросы
- Что-то я запутался во всех этих ключах, юнитах, узлах, пакетах, блоках...
- Клиент использует 100% процессорного времени!
- Клиент переключается между различными проектами вместо того, чтобы работать над тем, который я указал первым.
- Как заставить клиента работать X% времени над OGR и Y% - над RC5?
Частично обработанные блоки, возобновление работы
- Что происходит при перезагрузке (или зависании машины)? Теряются ли блоки?
- Клиент показывает неверное время.
- Что означает буква R в полоске с результами?
- Только что были обработаны два блока с R, как такое возможно?
- Что означает сообщение "Read partial block from another cpu/os/build. Marking entire block as unchecked" ("Считан блок, частично рассчитанный на другом процессоре/операционной системе/версии клиента. Помечаю весь блок как необработанный"), и как это исправить?
- Что означает индикатор эффективности у клиента?
Производительность
- На каком процессоре клиент работает быстрее всего?
- Похоже, что производительность падает, когда я не работаю на своем компьютере!
- Запрет кнопок мультимедийных клавиатур для повышения скорости клиента.
- На моем компьютере пакеты обсчитываются слишком долго. Их надо уменьшить.
- Есть ли какие-то подсказки по ускорению клиента?
- Win32 GUI: тестирование, запускаемое из меню, занимает слишком много процессорного времени.
- Cheyenne Bitware (Bitfax/Bitcomm) забирает 90% процессорного времени.
- Полезен ли разгон?
- Клиент работает значительно медленнее после смены ОС (либо материнской платы/процессора).
- Гиперпоточность (hyperthreading) дает мне два процессора, но почему клиент не работает в два раза быстрее?
Перенос на другие платформы
- Какие платформы поддерживаются?
- Я хочу портировать клиента на свою платформу. Могу ли я получить исходные тексты?
- Не был бы быстрее распределенный компьютер, использующий PVM, MOSIX, MPI, или Beowulf?
- Как насчет ядра, использующего процессоры видеоускорителей?
- Почему нет клиентов автоскачивающихся, автообновляющихся, или использующих подключаемые модули?
Разное
Yes there is.
You can find the "client download, configuration and operation" tutorial at:
http://www.distributed.net/docs/tutor_clients.html
Simply start the client from the directory you put it in.
If you have never run a client from that directory before, the
client will automatically start in "configuration mode". Change
the configuration as desired, save and quit when done. Then
restart the client.
If you are uninstalling an unauthorized installation of dnetc, please e-mail help@distributed.net so we can fully enforce our policies on unauthorized installation, and so we can provide you with the most current information.
Unix) and
may require some steps to 'uninstall' it. Refer to the above mentioned
URL for more information.
Instead of using the -hide, -quiet, or -install parameters, create a shortcut to DNETC.EXE in your startup folder.
Once you have created the shortcut, edit its properties and set the Run: dropdown to "Minimized."
Many clients support the -install switch to have the client set itself up to start automatically when the machine is booted. Others do not support this feature, and must be manually inserted/deleted from the boot sequence scripts. Those client that do support -install, also support -uninstall to stop the client from automatically starting.
Before configuring the system to launch the client on boot, please ensure that it can start normally.
Note: many clients provide some form of feedback on successful -install and -uninstall. To suppress those messages, use the -quiet switch, but make sure to specify it *before* the -[un]install switch (for example: dnetc -quiet -install), because the options that follow -install are the ones that the client is then 'installed' with (this feature is not available everywhere).
Special notes:
MacOS
OS/2
Windows (32bit)
Unix
distributed.net Faq-O-Matic : the Client software : Automatically starting the client at boot time :
MacOS
MacOS client distributions include an AppleScript that you can place in your Startup Items folder to cause the client be launched and the "Hide dnetc" option in the Applications Menu to be automatically activated. The client is still visible and can be re-activated from the Applications Menu however.
Alternatively, if the MacOS FBA (faceless background application) version of the dnetc client was distributed with your MacOS download, then you may use that version. The FBA version completely lacks any user interface at all, and will not even be visible from within the Applications Menu.
Newer distributions (2.8012.466+) of the client for MacOS may include a client that runs as a system extension. This enables the client to be launched before the finder starts and run without a user interface.
distributed.net Faq-O-Matic : the Client software : Automatically starting the client at boot time :
OS/2
The client for OS/2, unlike most other clients, does not insert
itself into the boot up sequence. Instead, it creates a shortcut in the
startup folder.
distributed.net Faq-O-Matic : the Client software : Automatically starting the client at boot time :
Windows (32bit)
32bit Windows clients are capable of running as 'services', which start when the machine starts, and don't shut down until the machine does. (ie, they survive logouts). The -install option configures the system to launch the
client as a service the next time the machine is booted.
Although services on Win9x and WinNT are dramatically different in terms of implementation, dnetc attempts to make the behavior between the two environments approximately equal.
Note that the (WinNT) client cannot run with "Allow service to interact
with desktop" enabled. This is because when the client starts, it does not
know whether it was started as a service or not (it does not depend on the
-svcrun switch). If it tried to initialize itself as a service, and wasn't
actually started as a service (from 'net start' or whatever), it would take
ages to start. So, since, under normal circumstances, the shell isn't
active/visible when the service starts, it uses this condition as an
indication of whether it should try to initialize itself as a service or not.
In order to reduce its footprint and other overhead, the client runs with an
implicit -quiet when started as service, so, even if it did not use the
check-for-shell described above, you wouldn't see anything.
The distributed.net client will fail to start as a service if the directory is marked for encryption. This limitation applies not specifically to the distributed.net client, but to any service or process that is running from a different logon context than the user the file is encrypted to. Encrypted directories and files can only be accessed by the user who created them, and services generally are started from within the "LocalSystem" user context.
Explicitly unencrypting each of the individual files within the directory is not sufficient, since new files created in that directory by the client will inherit the encryption from the parent directory.
Configuring the service to login as me (instead of as LocalSystem) seemed to fix it, but the safer approach is to keep the distributed.net client in an unencrypted directory, where no parent directory is encrypted either.
This limitation will also be apparent if you ever try to encrypt your Windows directory itself, or the base "Documents and Settings" directory (that contains the profile directories for multiple users, not just yourself), or the root directory of a hard drive that contains things that multiple users or the system itself needs to access. Generally speaking, only sensitive documents should be encrypted, and not application directories, or entire hard drives.
Older clients (<=.463) running as a WinNT service had a problem detecting modem connections. This is no longer an issue (it continues to be one for perproxy though), and to ensure that newer clients update their dependancy tables, you will need to re-"-install" the client.
Although not specific to NT service, be sure that the interface name that you've told the client to monitor is the correct interface name of your modem connection. However, typing the interface name incorrectly will prevent the client from detecting your modem connection when running as an NT Service or as an interactive process.
distributed.net Faq-O-Matic : the Client software : Automatically starting the client at boot time :
Unix
All Unix systems are capable of starting the distributed.net client from a
boot script or script in a boot script directory.
The quick and dirty way:
The long way:
#!/bin/sh if [ -x /path/to/dnetc ]; then /path/to/dnetc -quiet echo -n " dnetc" fiThe client will be stopped with a SIGTERM when when the machine is shutdown or rebooted.
[2.8011-464 and above support -[un]install for Linux (SysV-style)]
Create a file called '/etc[/rc.d]/init.d/dnetc' that looks like this:
#!/bin/sh
if [ -x /path/to/dnetc ]; then
case "$1" in
*start)
#make sure we're only running one client
/path/to/dnetc -quiet -shutdown
/path/to/dnetc -quiet
echo "Started distributed.net client"
;;
*stop)
/path/to/dnetc -quiet -shutdown
echo "Stopped distributed.net client"
sleep 2
;;
*)
echo "Syntax: $0 [start|stop]"
exit 1
;;
esac
fi
exit 0
Then create a symlink in each of the /etc[/rc.d]/rc?.d/ subdirectories
as follows:
For the 0, 1 and 6 runlevels (halt, single-user and reboot
respectively):
ln -s /etc[/rc.d]/init.d/dnetc /etc[/rc.d]/rc0.d/K10dnetc
ln -s /etc[/rc.d]/init.d/dnetc /etc[/rc.d]/rc1.d/K10dnetc
ln -s /etc[/rc.d]/init.d/dnetc /etc[/rc.d]/rc6.d/K10dnetc
For the 2, 3, 4 and 5 runlevels:
(runlevels 7, 8 and 9 are also valid, but not many
unix variants have them)
ln -s /etc[/rc.d]/init.d/dnetc /etc[/rc.d]/rc2.d/S90dnetc
ln -s /etc[/rc.d]/init.d/dnetc /etc[/rc.d]/rc3.d/S90dnetc
ln -s /etc[/rc.d]/init.d/dnetc /etc[/rc.d]/rc4.d/S90dnetc
ln -s /etc[/rc.d]/init.d/dnetc /etc[/rc.d]/rc5.d/S90dnetc
On entering a new runlevel, init(8) will run the scripts in
the /etc[/rc.d]/rc<runlevel>.d/ directory of
the runlevel it is entering. 'K' scripts are 'kill' scripts,
and will be run with the "stop" command. 'S' scripts
are 'start' scripts, and will be run with "start".According to the above described scheme then, the client will be started on entry into runlevel 2, 3, 4 or 5, and stopped on entry into any other runlevel.
Here it is. Distributed.net client
is supposed to be in /home/dnetc and a user called 'dnetc' must exist on the
system. The script launches dnetc as user 'dnetc' instead of 'root'. This is to controll the user's rights.
#!/bin/sh #Source function library. if [ -f /etc/init.d/functions ] ; then
. /etc/init.d/functionselif [ -f /etc/rc.d/init.d/functions ] ; then
. /etc/rc.d/init.d/functionselse
exit 0fi
echo -n "Starting Distributed.net client: "
if [ -f /var/lock/subsys/dnetc ]; then
failure
else
daemon --user=dnetc /home/dnetc/dnetc -quiet
RETVAL=$?
[ $RETVAL -eq 0 ] && touch /var/lock/subsys/dnetc || RETVAL=1
fi
echo
return $RETVAL
}
stop() {
echo -n "Shutting down Distributed.net client: "
killproc /home/dnetc/dnetc -TERM
RETVAL=$?
echo
[ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/dnetc
return $RETVAL
} case "$1" in
start)
start
;;
stop)
stop
;;
restart)
stop
start
;;
status)
status /home/dnetc/dnetc
;;
*)
echo "Syntax: $0 [start|stop|restart|status]"
exit 1
;;
esac
fi
exit 0
Starting the client with /? or -? or -h or --help (or any unrecognized word actually) will give you a list of valid command line switches.
eg: dnetc --help
Although not recommended since it is then a 'static' reference, the output of -help can be redirected to a file on all OSs except those that don't support redirection (NetWare), or those that only have a GUI (MacOS, Win16).
On 32bit Windows, for instance, 'dnetc.com -help > dnetc.hlp.txt' will
work just fine.
Yes, multiple clients/machines may "share" the same distributed.net ID (email address).
It is also possible to specify individual addresses of course, and has its own
set of advantages and disadvantages: Specifying multiple addresses may become cumbersome and difficult to track, particularly if you are maintaining a large number of computers. On the other hand, specifying separate email addresses has the advantage of allowing the stats server to show you block count information that is specific for each machine you are running the client on.
Most clients can take advantage of multiple processors, and those that do, will by default run with as many threads as there are processors.
The clients that cannot take advantage of multiple processors even when the
OS supports it, do so because of library or compatibility issues. Clients that fall in this category are HP/UX, SunOS 3, and Linux/S390. Under such circumstances, run one instance of the client per processor.
Some systems that other people have successfully used include:
REM dnetc install SET INSTALLDIR="%windir%\dnetc" IF EXIST %INSTALLDIR%\dnetc.exe GOTO ENDOFSCRIPT COPY \\server\sharename\dnetc.exe %INSTALLDIR% COPY \\server\sharename\dnetc.ini %INSTALLDIR% %INSTALLDIR%\dnetc.exe -quiet -install %INSTALLDIR%\dnetc.exe -svcstart [1] :ENDOFSCRIPT[1] newer clients support -svcstart (for both 9x and NT) to start a client previously installed as a service. Older clients require:
You will likely want to use "start /wait dnetc.exe -quiet -shutdown" since 9x/ME will typically not wait for GUI processes to run and finish before moving onto the next line in your batch file.
By default the client looks for an .ini file (where client configuration information is stored) with the same name (and directory) as the client [1]. You can make the client use a different .ini file with the '-ini
Thus, one solution then would be to create several copies of the client, each with a different name; one for each of the required configurations.
Another solution would be to have all machines sharing one copy of the client, where they would all end up sharing the same .ini file.
[1]On OSs where the client's directory cannot
be determined when the client is in the search path, the client will use the current directory.
Yes there is.
All clients support SOCKS4 and SOCKS5, as well as allow communications to go through HTTP proxies.
For a large number of machines behind a firewall
it may be simplest to run a personal proxy within the firewall
through which all client machines will transfer keyblocks.
If you suspect that your computer is being blocked by a firewall, it
can be helpful to see how your web browser is configured. If you can
figure out how it manages to talk freely with the world then
perhaps the same strategy can be used for the client. For
instance, from within Netscape you can select "Options" / "Network
Preferences" and see if it is configured to communicate through a
firewall. Often, you can just take this information and plug it
directly into the client and everything will work perfectly.
Simply use the schedule facilities within your operating system to script executions of "dnetc -pause" or "dnetc -unpause" or "dnetc -flush" (or whatever).
Virtually all operating systems support crontab or "at" events. Win9x systems can use the "Scheduled Tasks" feature.
The most common reason is because you are located behind a firewall and
the client can't get directly out to the internet. There are work arounds
as described in the next section. Intermittent network errors can also
occur due to poor conditions on your LAN, poor phone lines, or heavy
traffic on the internet itself. There have been some problems with earlier
versions of the client being overly sensitive to response times.
These problems have been mostly resolved.
Starting with build v2.8008-459 of the client, there is now a single unified Linux binary (for each processor architecture type), instead of separate ones for each architecture and library combination. The name resolution incompatibilities have been worked around by using "clever" dynamic symbol loading techniques, but this didn't work
very well (problems ranged from segfaults to hanging threads to simply
not-working).
So, from 2.8011-463 on, the client does not even bother trying to work around
the insanity introduced by glibc, and instead pipes/parses the output of 'host'.
Unfortunately, the only alternative to requiring bind-tools would be for distributed.net to release multiple, conflicting versions of the client for all the various libc permutations that exist.
If they change the ip address, or that server goes down, the client will fail. So I have the client running in a detached screen. And I check the output from time to time.
[Ed: This solution is not recommended.]
You can also setup dist.net to run offline, and setup a cron job to grab the IP of the keyserver and update the cache hourly. You may have to adjust the grep/sed expressions depending on your local flavor.
Just put the dist.net file in the directory where your dist.net client is, and adjust the paths, and it should work.
To simplify these directions, assume that "Laptop" refers to the
non-networked machine.
On the networked machine:
Yes you can! If you are sneakernetting clients, or you are having problems with the client connectivity through a firewall you can always get (fetch) and send (flush) work units via email.
You actually would send or be sent a complete buffer file.
Up-to-date instructions can be found by sending a blank email to:
Yes! The clients are designed for this and the file locking that
exists in network file systems will prevent multiple clients from
updating a buffer file at the same time. The client implements file-locking and automatic retrying so that it is pretty safe to allow multiple computers access the same buffers at the same time time.
Examples of supported file sharing mechanisms include Windows file-sharing (SMB/SAMBA), UNIX NFS, Netware server volumes, AppleShare, and others.
This is in fact one of the recommended ways if you have a small number of machines that are not directly connected to the Internet, but have at least one machine that is connected and can share a buffer file to the others.
However, if you have more than 20 or so machines, then you may want to consider running a personal proxy on the "Internet-connected" machine, and allow all of the other computers to retrieve blocks from the proxy.
To work around this, you can either disable checkpointing entirely, or set the checkpoint file to be saved to a path that is local (or at least different) for each machine.
The block size is really only a "request" by the client. Depending
on the fragmentation of the current keyspace we are working on, the
keyproxy may be forced to give you a block smaller than requested. This
is not a problem, just an oddity.
If the client is auto-dialing itself (or triggering your Operating System to automatically dial) too frequently, then that is because it does not have enough work to process during the time that you are offline. So you need to configure the client to keep enough workunits ready so that it will not run out. See the link below for information about how to configure your work thresholds.
The client actually cannot be configured to download a specific number of workunits--you instead configure how much "work" it try to maintain. When the client makes network connections, it will fetch enough additional workunits to fill itself up to that specified level.
The amount of work can be configured by specifying either one of the following for each contest:
a) number of workunits to buffer for that contest. Once you've determined how long it takes your computer to process a single workunit, you can approximate how many you will need to last the timeperiods when you are disconnected from the Internet. This value is set in the "Fetch work threshold" option in the client configuration.
b) number of hours to buffer for that contest. This will allow the client to do a quick-benchmark the that it can estimate how many workunits it will need, saving you the trouble of doing the above calculation yourself. This value is set in the "Fetch time threshold" option in the client configuration. (Note that you must be sure to set "Fetch work threshold" for that contest to "-1" for the "Fetch time threshold" to be obeyed).
"Dial-up Detection ONLY mode" will ensure that your client AUTOMATICALLY updates the total number of packets it has to process when you connect to the Internet. (That is, it will not ever trigger an autodial by itself--it will wait for you to establish an Internet connection.) At the same time, it also will automatically send back all completed data packets. This is all done without any intervention on your part
If you configure reasonable enough work thresholds that match your normal dialup usage behaviors, then the client will not usually need to make connections by itself because it will already have enough blocks.
If the client is auto-dialing itself (or triggering your Operating System to automatically dial) too frequently, then that is because it does not have enough work to process during the time that you are offline. So you need to configure the client to keep enough workunits ready so that it will not run out. See the link below for information about how to configure your work thresholds.
My network is not connected to Internet permanetly, it's on dialup. Often it is not online for a couple of days, so when i check my clients, they have begun to work on random keys.
Terms used by the distributed.net client
Obsolete, historical terms:
The first and second generation of clients ran only crypto-projects: RC5 and DES. These two projects were sponsored by RSA
and had a winner (and the prospect of monetary award), and as such were called contests.
Since a computer is capable of processing many hundreds of thousands of RC5 and DES keys per second, counting in single keys quickly becomes onerous,
and the very first generation of clients introduced the unit of 228 keys, as a handier unit of measure. These
first generation clients worked solely with this number, both as the number of keys it sent/received/processed as well as the number of keys used to represent "effort", or the "unit of of work" done, and what was displayed on the stats server. Consequently, this number of keys came to be known as a work-unit.
The second generation of clients introduced the ability to send/receive/process many more than 228 keys at once. For the purpose of (backwards-compatibility and) statistics, the 228 key "unit of of work" retained its meaning, but the term used to represent the number of keys being sent/received/processed at once had to be changed. Since the number of keys being sent/received/processed continued to be a multiple of 228, the unit being sent/received/processed was called a "block of work-units", or in short, a block.
With the introduction of non-crypto projects such as OGR, the terms contest, work-unit and block had to be reconsidered. OGR neither had a winner, nor did it use keys, nor did it have a fixed number of iterations ('keys' in crypto-parlance) per "unit-of-work", nor could multiple "units-of-work" be combined into "blocks of work-units" for sending/receiving/processing. Indeed, for OGR, there was a tendency to revert to the older meanings, since a stub is
a work-unit in the oldest sense of the term, both as a literal "unit of work" and as the unit that is sent/received/processed.
To overcome this confusion, more generic terms project, stats-unit and packet came to replace the older contest, work-unit and block respectively.
However, old habits die hard, and the old and new terms are often used interchangeably. While not technically correct in the generic sense, the old terms are still perfectly valid for the crypto-contests, errr... crypto-projects. :)
No, its not.
Unless configured otherwise, the client only uses *idle* time, ie, the cpu time that would go 'wasted' because no other task or application wanted it.
While you're watching cpu time statistics, you aren't doing anything else that might be consuming cpu time, and consequently you see the client using 100%.
If however you were to have another task running in the background that needed/was using cpu time, you'd see the client use that much less.
This is intentional behavior.
The client's configuration includes a "load-work precedence" setting that allows you to select the load order (and optionally disable specific ones). However, this setting does not prevent the client from working on other available contests if it does not have any more "ready work" for any of your earlier priority contests.
Notice that the normal behavior of the client is to not automatically attempt to fetch more blocks (for any contest) until blocks for all enabled-open contests have been depleted. Because of this, if you do not like the fact that your client is not working "solely" on the first contest that is enabled and open, you can do any of the following:
> how can I tell the client to spend 50% of time doing OGR and 50% doing RC5 .. ?
time:you can't and neither can the client. Its not possible to predict how much time it takes to do an OGR packet.
packets: But, if you were to count in completed packets
rather than time, then all you'd need to do is ensure that the thresholds
are equal, and over the long run client will do 50% OGR and 50% RC5.
If you want to work in just one project, simply disable all but that one project. For more information, refer to the description under Load-work precedence under the Buffer and Buffer Update option of the configuration menu.
Normally the client is able to shut down cleanly, the block is saved and will be resumed at the point it left off when you restart it later.
However, in the event that your computer crashes or you lose power and the client is not able to properly save its place. Blocks that have not been returned to the keyservers will eventually be redistributed. In order to accommodate slower clients and to minimize duplication of work
there is a long period after which a keyblock is assigned, minimally 90
days. If we reach the end of the keyspace without finding the winning key,
we will start back at the beginning and assign the unreturned blocks.
This checkpoint file will keep track of your work and update itself every few minutes. If your computer does crash (or you have to do a sudden reboot) the client can pick up almost right where it left off and not lose or discard a data packet.
The time reported by the clients is based on your computer's
internal clock however it is converted to and reported in UTC: see
A 'R' in the middle of a percentage bar stands for 'resume'. This
is the point at which the client was working on last time it was
shutdown; it just resumed and jumped to that point in the block. Note
that as a result of not having to process the entire block, resumed
blocks will be processed faster than normal blocks; the time difference
this makes obviously depends on where in the block it resumed.
Partially completed blocks can be 'buried' in the buff-in.* files; if
you routinely shut the client down and then fetch new blocks, new, full
blocks will be added to the buff-in.*. The partially completed blocks
will not resurface for a while, perhaps a couple of days.
Alternatively, you could create local batch files/scripts/shortcuts/etc. (depending on OS) that execute a common client w/ different -ini options on the command line, either pointing to a local .ini file or to a bunch of different .ini files w/ different filenames on the network drive. Even more elegantly, if the path to the local .ini file is the same across all machines running from the shared volume, you could have one batch file/script/shortcut on the shared volume that points to a local .ini file w/ a custom configuration.
You can find the "client networking" tutorial at:
http://www.distributed.net/docs/tutor_netopt.html
Consider also looking at the following document:
http://www.distributed.net/docs/tutor_netopt.html#no_firewall
If you are getting "Unable to resolve..." messages from the Linux client, you may be having a compatibility problem with the "glibc" library. There are two common, incompatible versions of glibc: glibc2.0 and glibc2.1. You will notice that there are two Linux clients with "glibc20" and glibc21" in their file names. You must choose the correct version in order for name resolution to work. If you are not sure which glibc version you have, just try the other client to see if it works better.
I noticed that (at least on Unix) a running client does not take any notice if you change DNS servers. Look out for spurious UDP packets to the old nameserver (netstat -tn), and a failure to flush buffers once the old nameserver has packed up and gone home. Restarting the client will fix this.
This applies to any application that uses the ISC resolver, which only loads /etc/resolv.conf (into static storage) once.
If you find that your Linux client is reporting this error, it's because you do not have the bind tools installed on your computer. Look for a "bind-tools" binary package in whichever packaging format is appropriate for your particular flavor of linux.
To simply set the address manually, also solves the problem. By using nslookup or ping, I found the IP address of the name it failed to resolve. Then it was just to start the client with:
$ dnetc -a 145.89.128.249
#!/bin/bash
# script to start, stop, restart, or update cache for the dist.net client
# is dist.net client on?
distnetON=$(ps --no-headers -o %c -C dnetc)
function start() {
# run dist.net client offline
/usr/local/dist.net/dnetc -quiet -runoffline
echo "Started distributed.net client"
}
function stop() {
/usr/local/dist.net/dnetc -quiet -shutdown
echo "Stopped distributed.net client"
sleep 2
}
function update() {
# ping the keyserver, grab the ip from the output, and update the caches
/usr/local/dist.net/dnetc -quiet -update -a $(ping -n -c 1 us.v29.distributed.net | grep \( | sed -e 's/^PI.\+\.net (//g' -e 's/) fro.\+$//g')
}
if [ -x /usr/local/dist.net/dnetc ]; then
case "$1" in
start|restart)
# make sure that there are no clients running
if [ "$distnetON" = "dnetc" ]; then stop; fi
# now start it up
start
;;
stop)
if [ "$distnetON" = "dnetc" ]; then stop; fi
;;
update)
if [ -e /var/smoothwall/red/active ]; then update; fi
;;
*)
echo "Syntax: $0 [start|restart|update|stop]"
exit 1
;;
esac
fi
exit 0
/etc/cron.hourly/updateksip:
#!/bin/bash
# cron.hourly script to update the dist.net clients key server IP address
# if dist.net client not running, then start it
if [ "$(ps --no-headers -o %c -C dnetc)" != "dnetc" ]; then
#/usr/local/dist.net/dist.net start;
echo "not running"
fi
# check if red interface is connected
if [ -e /var/smoothwall/red/active ]; then
# update in/out caches
/usr/local/dist.net/dist.net update
# write to smoothwall log
logger -t smoothwall "dist.net: cache updated"
fi
exit 0
On the laptop:
fetch@distributed.net and/or
flush@distributed.net
Be sure to understand that while it is possible to share input and output buffers between multiple clients over network filesharing, checkpoint files must not be shared! This is very important, because doing so will cause all of your clients to do the same duplicated (wasted) work.
Additionally, since your dialup requires a password, it is silly to allow the client to ever trigger auto-dial by itself. Therefore, you should configure the client to use the "Lurk-Only" mode, that is described in the link below.
This question has already been answered with this post:
I use a modem. How can I get the client to download enough packets?
One last note for modem users. It is beneficial to enable the "Lurk-only" mode. This is available under: "Buffer and Buffer Update Options" / "Keyserver-client Connectivity Options" / "Modem Detection Options" / "Dial-up Detection ONLY mode".
If you don't mind allowing the client to occasionally cause an auto-dial, then instead of "lurk only" mode, try the "lurk" mode ("dialup detection mode"). In that configuration, the client will opportunistically fetch/flush when it sees your modem is connected. However, it will also automatically dial (and automatically disconnect when done) if it ever runs out of blocks.
If your client is causing your Operating System to auto-dialing your network connection for you, but the client doesn't ever disconnect your modem, then that is because you have not told the client that you have a dialup connection. See the link below for information about how to configure the "lurk" or "lurk only" mode.
This question has already been answered with this post:
I use a modem. How can I get the client to download enough packets?
This question has already been answered with this post:
I use a modem. How can I get the client to download enough packets?
(ie, 1 to 32 stats-units)
(ie, 0.01 to N.nn stats-units)
First Generation Term
Second Generation Term
Current Term
endevour/undertaking
contest
contest
project
unit used by stats
work-unit
work-unit
stats-unit
unit sent/received/processed
work-unit
block
packet
Obviously, if you wanted to crunch, say, 20% RC5 and 80% OGR, you'd simply
set the OGR thresholds to be 4 times that of the RC5 threshold.
One other way to make sure your computer doesn't lose it's work even when your computer crashes and you have to reboot is to use a checkpoint file.
[In the client configuration under "Buffer and Buffer Update Options" >> "Checkpoint Filename"].
In some short term projects, such as DES, blocks may be reissued in less than 90 days. In these situations it best to keep your buffers small to avoid duplicated effort. When such projects are underway please check back the .plans frequently to monitor the status.
What is UTC? Is that like GMT or something?.
This makes comparing logs and updating the stats simpler.