rsyncd.conf
Section: (5)Updated: 8 May 2009
Index Return to Main Contents
NAME
rsyncd.conf --- configuration file for rsync in daemon modeSYNOPSIS
rsyncd.conf
DESCRIPTION
The rsyncd.conf file is the runtime configuration file for rsync when run as an rsync daemon.
The rsyncd.conf file controls authentication, access, logging and available modules.
FILE FORMAT
The file consists of modules and parameters. A module begins with the name of the module in square brackets and continues until the next module begins. Modules contain parameters of the form lqname = valuerq.
The file is line-based --- that is, each newline-terminated line represents either a comment, a module name or a parameter.
Only the first equals sign in a parameter is significant. Whitespace before or after the first equals sign is discarded. Leading, trailing and internal whitespace in module and parameter names is irrelevant. Leading and trailing whitespace in a parameter value is discarded. Internal whitespace within a parameter value is retained verbatim.
Any line beginning with a hash (#) is ignored, as are lines containing only whitespace.
Any line ending in a \ is lqcontinuedrq on the next line in the customary UNIX fashion.
The values following the equals sign in parameters are all either a string (no quotes needed) or a boolean, which may be given as yes/no, 0/1 or true/false. Case is not significant in boolean values, but is preserved in string values.
LAUNCHING THE RSYNC DAEMON
The rsync daemon is launched by specifying the --daemon option to rsync.
The daemon must run with root privileges if you wish to use chroot, to bind to a port numbered under 1024 (as is the default 873), or to set file ownership. Otherwise, it must just have permission to read and write the appropriate data, log, and lock files.
You can launch it either via inetd, as a stand-alone daemon, or from an rsync client via a remote shell. If run as a stand-alone daemon then just run the command lqrsync --daemonrq from a suitable startup script.
When run via inetd you should add a line like this to /etc/services:
rsync 873/tcp
and a single line something like this to /etc/inetd.conf:
rsync stream tcp nowait root /usr/bin/rsync rsyncd --daemon
Replace lq/usr/bin/rsyncrq with the path to where you have rsync installed on your system. You will then need to send inetd a HUP signal to tell it to reread its config file.
Note that you should not send the rsync daemon a HUP signal to force it to reread the rsyncd.conf file. The file is re-read on each client connection.
GLOBAL PARAMETERS
The first parameters in the file (before a [module] header) are the global parameters.
You may also include any module parameters in the global part of the config file in which case the supplied value will override the default for that parameter.
- motd file
- This parameter allows you to specify a lqmessage of the dayrq to display to clients on each connect. This usually contains site information and any legal notices. The default is no motd file.
- pid file
- This parameter tells the rsync daemon to write its process ID to that file. If the file already exists, the rsync daemon will abort rather than overwrite the file.
- port
- You can override the default port the daemon will listen on by specifying this value (defaults to 873). This is ignored if the daemon is being run by inetd, and is superseded by the --port command-line option.
- address
- You can override the default IP address the daemon will listen on by specifying this value. This is ignored if the daemon is being run by inetd, and is superseded by the --address command-line option.
- socket options
- This parameter can provide endless fun for people who like to tune their systems to the utmost degree. You can set all sorts of socket options which may make transfers faster (or slower!). Read the man page for the setsockopt() system call for details on some of the options you may be able to set. By default no special socket options are set. These settings can also be specified via the --sockopts command-line option.
MODULE PARAMETERS
After the global parameters you should define a number of modules, each module exports a directory tree as a symbolic name. Modules are exported by specifying a module name in square brackets [module] followed by the parameters for that module. The module name cannot contain a slash or a closing square bracket. If the name contains whitespace, each internal sequence of whitespace will be changed into a single space, while leading or trailing whitespace will be discarded.
- comment
- This parameter specifies a description string that is displayed next to the module name when clients obtain a list of available modules. The default is no comment.
- path
- This parameter specifies the directory in the daemon's filesystem to make available in this module. You must specify this parameter for each module in rsyncd.conf.
- use chroot
- If lquse chrootrq is true, the rsync daemon will chroot to the lqpathrq before starting the file transfer with the client. This has the advantage of extra protection against possible implementation security holes, but it has the disadvantages of requiring super-user privileges, of not being able to follow symbolic links that are either absolute or outside of the new root path, and of complicating the preservation of users and groups by name (see below).
- As an additional safety feature, you can specify a dot-dir in the module's lqpathrq to indicate the point where the chroot should occur. This allows rsync to run in a chroot with a non-"/rq path for the top of the transfer hierarchy. Doing this guards against unintended library loading (since those absolute paths will not be inside the transfer hierarchy unless you have used an unwise pathname), and lets you setup libraries for the chroot that are outside of the transfer. For example, specifying lq/var/rsync/./module1rq will chroot to the lq/var/rsyncrq directory and set the inside-chroot path to lq/module1rq. If you had omitted the dot-dir, the chroot would have used the whole path, and the inside-chroot path would have been lq/rq.
- When lquse chrootrq is false or the inside-chroot path is not lq/rq, rsync will: (1) munge symlinks by default for security reasons (see lqmunge symlinksrq for a way to turn this off, but only if you trust your users), (2) substitute leading slashes in absolute paths with the module's path (so that options such as --backup-dir, --compare-dest, etc. interpret an absolute path as rooted in the module's lqpathrq dir), and (3) trim lq..rq path elements from args if rsync believes they would escape the module hierarchy. The default for lquse chrootrq is true, and is the safer choice (especially if the module is not read-only).
- When this parameter is enabled, rsync will not attempt to map users and groups by name (by default), but instead copy IDs as though --numeric-ids had been specified. In order to enable name-mapping, rsync needs to be able to use the standard library functions for looking up names and IDs (i.e. getpwuid() , getgrgid() , getpwname() , and getgrnam() ). This means the rsync process in the chroot hierarchy will need to have access to the resources used by these library functions (traditionally /etc/passwd and /etc/group, but perhaps additional dynamic libraries as well).
- If you copy the necessary resources into the module's chroot area, you should protect them through your OS's normal user/group or ACL settings (to prevent the rsync module's user from being able to change them), and then hide them from the user's view via lqexcluderq (see how in the discussion of that parameter). At that point it will be safe to enable the mapping of users and groups by name using the lqnumeric idsrq daemon parameter (see below).
- Note also that you are free to setup custom user/group information in the chroot area that is different from your normal system. For example, you could abbreviate the list of users and groups.
- numeric ids
- Enabling this parameter disables the mapping of users and groups by name for the current daemon module. This prevents the daemon from trying to load any user/group-related files or libraries. This enabling makes the transfer behave as if the client had passed the --numeric-ids command-line option. By default, this parameter is enabled for chroot modules and disabled for non-chroot modules.
- A chroot-enabled module should not have this parameter enabled unless you've taken steps to ensure that the module has the necessary resources it needs to translate names, and that it is not possible for a user to change those resources.
- munge symlinks
- This parameter tells rsync to modify all incoming symlinks in a way that makes them unusable but recoverable (see below). This should help protect your files from user trickery when your daemon module is writable. The default is disabled when lquse chrootrq is on and the inside-chroot path is lq/rq, otherwise it is enabled.
- If you disable this parameter on a daemon that is not read-only, there are tricks that a user can play with uploaded symlinks to access daemon-excluded items (if your module has any), and, if lquse chrootrq is off, rsync can even be tricked into showing or changing data that is outside the module's path (as access-permissions allow).
- The way rsync disables the use of symlinks is to prefix each one with the string lq/rsyncd-munged/rq. This prevents the links from being used as long as that directory does not exist. When this parameter is enabled, rsync will refuse to run if that path is a directory or a symlink to a directory. When using the lqmunge symlinksrq parameter in a chroot area that has an inside-chroot path of lq/rq, you should add lq/rsyncd-munged/rq to the exclude setting for the module so that a user can't try to create it.
- Note: rsync makes no attempt to verify that any pre-existing symlinks in the module's hierarchy are as safe as you want them to be (unless, of course, it just copied in the whole hierarchy). If you setup an rsync daemon on a new area or locally add symlinks, you can manually protect your symlinks from being abused by prefixing lq/rsyncd-munged/rq to the start of every symlink's value. There is a perl script in the support directory of the source code named lqmunge-symlinksrq that can be used to add or remove this prefix from your symlinks.
- When this parameter is disabled on a writable module and lquse chrootrq is off (or the inside-chroot path is not lq/rq), incoming symlinks will be modified to drop a leading slash and to remove lq..rq path elements that rsync believes will allow a symlink to escape the module's hierarchy. There are tricky ways to work around this, though, so you had better trust your users if you choose this combination of parameters.
- charset
- This specifies the name of the character set in which the module's filenames are stored. If the client uses an --iconv option, the daemon will use the value of the lqcharsetrq parameter regardless of the character set the client actually passed. This allows the daemon to support charset conversion in a chroot module without extra files in the chroot area, and also ensures that name-translation is done in a consistent manner. If the lqcharsetrq parameter is not set, the --iconv option is refused, just as if lqiconvrq had been specified via lqrefuse optionsrq.
- If you wish to force users to always use --iconv for a particular module, add lqno-iconvrq to the lqrefuse optionsrq parameter. Keep in mind that this will restrict access to your module to very new rsync clients.
- max connections
- This parameter allows you to specify the maximum number of simultaneous connections you will allow. Any clients connecting when the maximum has been reached will receive a message telling them to try later. The default is 0, which means no limit. A negative value disables the module. See also the lqlock filerq parameter.
- log file
- When the lqlog filerq parameter is set to a non-empty string, the rsync daemon will log messages to the indicated file rather than using syslog. This is particularly useful on systems (such as AIX) where syslog() doesn't work for chrooted programs. The file is opened before chroot() is called, allowing it to be placed outside the transfer. If this value is set on a per-module basis instead of globally, the global log will still contain any authorization failures or config-file error messages.
- If the daemon fails to open the specified file, it will fall back to using syslog and output an error about the failure. (Note that the failure to open the specified log file used to be a fatal error.)
- syslog facility
- This parameter allows you to specify the syslog facility name to use when logging messages from the rsync daemon. You may use any standard syslog facility name which is defined on your system. Common names are auth, authpriv, cron, daemon, ftp, kern, lpr, mail, news, security, syslog, user, uucp, local0, local1, local2, local3, local4, local5, local6 and local7. The default is daemon. This setting has no effect if the lqlog filerq setting is a non-empty string (either set in the per-modules settings, or inherited from the global settings).
- max verbosity
- This parameter allows you to control the maximum amount of verbose information that you'll allow the daemon to generate (since the information goes into the log file). The default is 1, which allows the client to request one level of verbosity.
- lock file
- This parameter specifies the file to use to support the lqmax connectionsrq parameter. The rsync daemon uses record locking on this file to ensure that the max connections limit is not exceeded for the modules sharing the lock file. The default is /var/run/rsyncd.lock.
- read only
- This parameter determines whether clients will be able to upload files or not. If lqread onlyrq is true then any attempted uploads will fail. If lqread onlyrq is false then uploads will be possible if file permissions on the daemon side allow them. The default is for all modules to be read only.
- write only
- This parameter determines whether clients will be able to download files or not. If lqwrite onlyrq is true then any attempted downloads will fail. If lqwrite onlyrq is false then downloads will be possible if file permissions on the daemon side allow them. The default is for this parameter to be disabled.
- list
- This parameter determines if this module should be listed when the client asks for a listing of available modules. By setting this to false you can create hidden modules. The default is for modules to be listable.
- uid
- This parameter specifies the user name or user ID that file transfers to and from that module should take place as when the daemon was run as root. In combination with the lqgidrq parameter this determines what file permissions are available. The default is uid -2, which is normally the user lqnobodyrq.
- gid
- This parameter specifies the group name or group ID that file transfers to and from that module should take place as when the daemon was run as root. This complements the lquidrq parameter. The default is gid -2, which is normally the group lqnobodyrq.
- fake super
- Setting lqfake super = yesrq for a module causes the daemon side to behave as if the --fake-user command-line option had been specified. This allows the full attributes of a file to be stored without having to have the daemon actually running as root.
- filter
- The daemon has its own filter chain that determines what files it will let the client access. This chain is not sent to the client and is independent of any filters the client may have specified. Files excluded by the daemon filter chain (daemon-excluded files) are treated as non-existent if the client tries to pull them, are skipped with an error message if the client tries to push them (triggering exit code 23), and are never deleted from the module. You can use daemon filters to prevent clients from downloading or tampering with private administrative files, such as files you may add to support uid/gid name translations.
- The daemon filter chain is built from the lqfilterrq, lqinclude fromrq, lqincluderq, lqexclude fromrq, and lqexcluderq parameters, in that order of priority. Anchored patterns are anchored at the root of the module. To prevent access to an entire subtree, for example, lq/secretrq, you must exclude everything in the subtree; the easiest way to do this is with a triple-star pattern like lq/secret/***rq.
- The lqfilterrq parameter takes a space-separated list of daemon filter rules, though it is smart enough to know not to split a token at an internal space in a rule (e.g. lq- /foo --- /barrq is parsed as two rules). You may specify one or more merge-file rules using the normal syntax. Only one lqfilterrq parameter can apply to a given module in the config file, so put all the rules you want in a single parameter. Note that per-directory merge-file rules do not provide as much protection as global rules, but they can be used to make --delete work better during a client download operation if the per-dir merge files are included in the transfer and the client requests that they be used.
- exclude
- This parameter takes a space-separated list of daemon exclude patterns. As with the client --exclude option, patterns can be qualified with lq- rq or lq+ rq to explicitly indicate exclude/include. Only one lqexcluderq parameter can apply to a given module. See the lqfilterrq parameter for a description of how excluded files affect the daemon.
- include
- Use an lqincluderq to override the effects of the lqexcluderq parameter. Only one lqincluderq parameter can apply to a given module. See the lqfilterrq parameter for a description of how excluded files affect the daemon.
- exclude from
- This parameter specifies the name of a file on the daemon that contains daemon exclude patterns, one per line. Only one lqexclude fromrq parameter can apply to a given module; if you have multiple exclude-from files, you can specify them as a merge file in the lqfilterrq parameter. See the lqfilterrq parameter for a description of how excluded files affect the daemon.
- include from
- Analogue of lqexclude fromrq for a file of daemon include patterns. Only one lqinclude fromrq parameter can apply to a given module. See the lqfilterrq parameter for a description of how excluded files affect the daemon.
- incoming chmod
- This parameter allows you to specify a set of comma-separated chmod strings that will affect the permissions of all incoming files (files that are being received by the daemon). These changes happen after all other permission calculations, and this will even override destination-default and/or existing permissions when the client does not specify --perms. See the description of the --chmod rsync option and the chmod(1) manpage for information on the format of this string.
- outgoing chmod
- This parameter allows you to specify a set of comma-separated chmod strings that will affect the permissions of all outgoing files (files that are being sent out from the daemon). These changes happen first, making the sent permissions appear to be different than those stored in the filesystem itself. For instance, you could disable group write permissions on the server while having it appear to be on to the clients. See the description of the --chmod rsync option and the chmod(1) manpage for information on the format of this string.
- auth users
- This parameter specifies a comma and space-separated list of usernames that will be allowed to connect to this module. The usernames do not need to exist on the local system. The usernames may also contain shell wildcard characters. If lqauth usersrq is set then the client will be challenged to supply a username and password to connect to the module. A challenge response authentication protocol is used for this exchange. The plain text usernames and passwords are stored in the file specified by the lqsecrets filerq parameter. The default is for all users to be able to connect without a password (this is called lqanonymous rsyncrq).
- See also the lqCONNECTING TO AN RSYNC DAEMON OVER A REMOTE SHELL PROGRAMrq section in rsync(1) for information on how handle an rsyncd.conf-level username that differs from the remote-shell-level username when using a remote shell to connect to an rsync daemon.
- secrets file
- This parameter specifies the name of a file that contains the username:password pairs used for authenticating this module. This file is only consulted if the lqauth usersrq parameter is specified. The file is line based and contains username:password pairs separated by a single colon. Any line starting with a hash (#) is considered a comment and is skipped. The passwords can contain any characters but be warned that many operating systems limit the length of passwords that can be typed at the client end, so you may find that passwords longer than 8 characters don't work.
- There is no default for the lqsecrets filerq parameter, you must choose a name (such as /etc/rsyncd.secrets). The file must normally not be readable by lqotherrq; see lqstrict modesrq.
- strict modes
- This parameter determines whether or not the permissions on the secrets file will be checked. If lqstrict modesrq is true, then the secrets file must not be readable by any user ID other than the one that the rsync daemon is running under. If lqstrict modesrq is false, the check is not performed. The default is true. This parameter was added to accommodate rsync running on the Windows operating system.
- hosts allow
- This parameter allows you to specify a list of patterns that are matched against a connecting clients hostname and IP address. If none of the patterns match then the connection is rejected.
- Each pattern can be in one of five forms:
-
-
- o
- a dotted decimal IPv4 address of the form a.b.c.d, or an IPv6 address of the form a:b:c::d:e:f. In this case the incoming machine's IP address must match exactly.
- o
- an address/mask in the form ipaddr/n where ipaddr is the IP address and n is the number of one bits in the netmask. All IP addresses which match the masked IP address will be allowed in.
- o
- an address/mask in the form ipaddr/maskaddr where ipaddr is the IP address and maskaddr is the netmask in dotted decimal notation for IPv4, or similar for IPv6, e.g. ffff:ffff:ffff:ffff:: instead of /64. All IP addresses which match the masked IP address will be allowed in.
- o
- a hostname. The hostname as determined by a reverse lookup will be matched (case insensitive) against the pattern. Only an exact match is allowed in.
- o
- a hostname pattern using wildcards. These are matched using the same rules as normal unix filename matching. If the pattern matches then the client is allowed in.
-
- Note IPv6 link-local addresses can have a scope in the address specification:
-
-
fe80::1%link1
fe80::%link1/64
fe80::%link1/ffff:ffff:ffff:ffff::
-
fe80::1%link1
- You can also combine lqhosts allowrq with a separate lqhosts denyrq parameter. If both parameters are specified then the lqhosts allowrq parameter is checked first and a match results in the client being able to connect. The lqhosts denyrq parameter is then checked and a match means that the host is rejected. If the host does not match either the lqhosts allowrq or the lqhosts denyrq patterns then it is allowed to connect.
- The default is no lqhosts allowrq parameter, which means all hosts can connect.
- hosts deny
- This parameter allows you to specify a list of patterns that are matched against a connecting clients hostname and IP address. If the pattern matches then the connection is rejected. See the lqhosts allowrq parameter for more information.
- The default is no lqhosts denyrq parameter, which means all hosts can connect.
- ignore errors
- This parameter tells rsyncd to ignore I/O errors on the daemon when deciding whether to run the delete phase of the transfer. Normally rsync skips the --delete step if any I/O errors have occurred in order to prevent disastrous deletion due to a temporary resource shortage or other I/O error. In some cases this test is counter productive so you can use this parameter to turn off this behavior.
- ignore nonreadable
- This tells the rsync daemon to completely ignore files that are not readable by the user. This is useful for public archives that may have some non-readable files among the directories, and the sysadmin doesn't want those files to be seen at all.
- transfer logging
- This parameter enables per-file logging of downloads and uploads in a format somewhat similar to that used by ftp daemons. The daemon always logs the transfer at the end, so if a transfer is aborted, no mention will be made in the log file.
- If you want to customize the log lines, see the lqlog formatrq parameter.
- log format
- This parameter allows you to specify the format used for logging file transfers when transfer logging is enabled. The format is a text string containing embedded single-character escape sequences prefixed with a percent (%) character. An optional numeric field width may also be specified between the percent and the escape letter (e.g. lq%-50n %8l %07prq).
- The default log format is lq%o %h [%a] %m (%u) %f %lrq, and a lq%t [%p] rq is always prefixed when using the lqlog filerq parameter. (A perl script that will summarize this default log format is included in the rsync source code distribution in the lqsupportrq subdirectory: rsyncstats.)
- The single-character escapes that are understood are as follows:
-
-
- o
- %a the remote IP address
- o
- %b the number of bytes actually transferred
- o
- %B the permission bits of the file (e.g. rwxrwxrwt)
- o
- %c the total size of the block checksums received for the basis file (only when sending)
- o
- %f the filename (long form on sender; no trailing lq/rq)
- o
- %G the gid of the file (decimal) or lqDEFAULTrq
- o
- %h the remote host name
- o
- %i an itemized list of what is being updated
- o
- %l the length of the file in bytes
- o
- %L the string lq -> SYMLINKrq, lq => HARDLINKrq, or lqrq (where SYMLINK or HARDLINK is a filename)
- o
- %m the module name
- o
- %M the last-modified time of the file
- o
- %n the filename (short form; trailing lq/rq on dir)
- o
- %o the operation, which is lqsendrq, lqrecvrq, or lqdel.rq (the latter includes the trailing period)
- o
- %p the process ID of this rsync session
- o
- %P the module path
- o
- %t the current date time
- o
- %u the authenticated username or an empty string
- o
- %U the uid of the file (decimal)
-
- For a list of what the characters mean that are output by lq%irq, see the --itemize-changes option in the rsync manpage.
- Note that some of the logged output changes when talking with older rsync versions. For instance, deleted files were only output as verbose messages prior to rsync 2.6.4.
- timeout
- This parameter allows you to override the clients choice for I/O timeout for this module. Using this parameter you can ensure that rsync won't wait on a dead client forever. The timeout is specified in seconds. A value of zero means no timeout and is the default. A good choice for anonymous rsync daemons may be 600 (giving a 10 minute timeout).
- refuse options
- This parameter allows you to specify a space-separated list of rsync command line options that will be refused by your rsync daemon. You may specify the full option name, its one-letter abbreviation, or a wild-card string that matches multiple options. For example, this would refuse --checksum (-c) and all the various delete options:
-
- refuse options = c delete
- The reason the above refuses all delete options is that the options imply --delete, and implied options are refused just like explicit options. As an additional safety feature, the refusal of lqdeleterq also refuses remove-source-files when the daemon is the sender; if you want the latter without the former, instead refuse lqdelete-*rq --- that refuses all the delete modes without affecting --remove-source-files.
- When an option is refused, the daemon prints an error message and exits. To prevent all compression when serving files, you can use lqdont compress = *rq (see below) instead of lqrefuse options = compressrq to avoid returning an error to a client that requests compression.
- dont compress
- This parameter allows you to select filenames based on wildcard patterns that should not be compressed when pulling files from the daemon (no analogous parameter exists to govern the pushing of files to a daemon). Compression is expensive in terms of CPU usage, so it is usually good to not try to compress files that won't compress well, such as already compressed files.
- The lqdont compressrq parameter takes a space-separated list of case-insensitive wildcard patterns. Any source filename matching one of the patterns will not be compressed during transfer.
- See the --skip-compress parameter in the rsync(1) manpage for the list of file suffixes that are not compressed by default. Specifying a value for the lqdont compressrq parameter changes the default when the daemon is the sender.
- pre-xfer exec, post-xfer exec
- You may specify a command to be run before and/or after the transfer. If the pre-xfer exec command fails, the transfer is aborted before it begins.
- The following environment variables will be set, though some are specific to the pre-xfer or the post-xfer environment:
-
-
- o
- RSYNC_MODULE_NAME: The name of the module being accessed.
- o
- RSYNC_MODULE_PATH: The path configured for the module.
- o
- RSYNC_HOST_ADDR: The accessing host's IP address.
- o
- RSYNC_HOST_NAME: The accessing host's name.
- o
- RSYNC_USER_NAME: The accessing user's name (empty if no user).
- o
- RSYNC_PID: A unique number for this transfer.
- o
- RSYNC_REQUEST: (pre-xfer only) The module/path info specified by the user (note that the user can specify multiple source files, so the request can be something like lqmod/path1 mod/path2rq, etc.).
- o
- RSYNC_ARG#: (pre-xfer only) The pre-request arguments are set in these numbered values. RSYNC_ARG0 is always lqrsyncdrq, and the last value contains a single period.
- o
- RSYNC_EXIT_STATUS: (post-xfer only) the server side's exit value. This will be 0 for a successful run, a positive value for an error that the server generated, or a -1 if rsync failed to exit properly. Note that an error that occurs on the client side does not currently get sent to the server side, so this is not the final exit status for the whole transfer.
- o
- RSYNC_RAW_STATUS: (post-xfer only) the raw exit value from waitpid() .
-
- Even though the commands can be associated with a particular module, they are run using the permissions of the user that started the daemon (not the module's uid/gid setting) without any chroot restrictions.
AUTHENTICATION STRENGTH
The authentication protocol used in rsync is a 128 bit MD4 based challenge response system. This is fairly weak protection, though (with at least one brute-force hash-finding algorithm publicly available), so if you want really top-quality security, then I recommend that you run rsync over ssh. (Yes, a future version of rsync will switch over to a stronger hashing method.)
Also note that the rsync daemon protocol does not currently provide any encryption of the data that is transferred over the connection. Only authentication is provided. Use ssh as the transport if you want encryption.
Future versions of rsync may support SSL for better authentication and encryption, but that is still being investigated.
EXAMPLES
A simple rsyncd.conf file that allow anonymous rsync to a ftp area at /home/ftp would be:
[ftp] path = /home/ftp comment = ftp export area
A more sophisticated example would be:
uid = nobody gid = nobody use chroot = yes max connections = 4 syslog facility = local5 pid file = /var/run/rsyncd.pid [ftp] path = /var/ftp/./pub comment = whole ftp area (approx 6.1 GB) [sambaftp] path = /var/ftp/./pub/samba comment = Samba ftp area (approx 300 MB) [rsyncftp] path = /var/ftp/./pub/rsync comment = rsync ftp area (approx 6 MB) [sambawww] path = /public_html/samba comment = Samba WWW pages (approx 240 MB) [cvs] path = /data/cvs comment = CVS repository (requires authentication) auth users = tridge, susan secrets file = /etc/rsyncd.secrets
The /etc/rsyncd.secrets file would look something like this:
-
tridge:mypass
susan:herpass
FILES
/etc/rsyncd.conf or rsyncd.conf
SEE ALSO
rsync(1)
DIAGNOSTICS
BUGS
Please report bugs! The rsync bug tracking system is online at http://rsync.samba.org/
VERSION
This man page is current for version 3.0.6 of rsync.
CREDITS
rsync is distributed under the GNU public license. See the file COPYING for details.
The primary ftp site for rsync is ftp://rsync.samba.org/pub/rsync.
A WEB site is available at http://rsync.samba.org/
We would be delighted to hear from you if you like this program.
This program uses the zlib compression library written by Jean-loup Gailly and Mark Adler.
THANKS
Thanks to Warren Stanley for his original idea and patch for the rsync daemon. Thanks to Karsten Thygesen for his many suggestions and documentation!
AUTHOR
rsync was written by Andrew Tridgell and Paul Mackerras. Many people have later contributed to it.
Mailing lists for support and development are available at http://lists.samba.org
Index
- NAME
- SYNOPSIS
- DESCRIPTION
- FILE FORMAT
- LAUNCHING THE RSYNC DAEMON
- GLOBAL PARAMETERS
- MODULE PARAMETERS
- AUTHENTICATION STRENGTH
- EXAMPLES
- FILES
- SEE ALSO
- DIAGNOSTICS
- BUGS
- VERSION
- CREDITS
- THANKS
- AUTHOR
This document was created by man2html, using the manual pages.
Time: 05:34:00 GMT, December 24, 2015


Hi Everyone, My name is Rohit Chawla, I'm 18 years old as of now and currently a student and have passed the 12th grade.


|
xpcc
|
FreeRTOS is a real-time operating system for embedded devices, being ported to several microcontrollers. More...
Classes | |
| class | xpcc::rtos::Mutex |
| Mutex. More... | |
| class | xpcc::rtos::QueueBase |
| Queue base class. More... | |
| class | xpcc::rtos::Queue< T > |
| Thread-safe Queue. More... | |
| class | xpcc::rtos::Scheduler |
| FreeRTOS Scheduler. More... | |
| class | xpcc::rtos::Semaphore |
| Counting semaphore. More... | |
| class | xpcc::rtos::Thread |
| Thread. More... | |
Macros | |
| #define | TIME_LOOP(frequency) |
| Create a timed periodic loop. More... | |
| #define | MILLISECONDS |
| Convert between scheduler ticks and milliseconds. More... | |
It is distributed under the GPL with an optional exception. The exception permits users' proprietary code to remain closed source while maintaining the kernel itself as open source, thereby facilitating the use of FreeRTOS in proprietary applications.
Key features:
| #define TIME_LOOP | ( | frequency | ) |
Example:
| frequency | Frequency in ticks |
| #define MILLISECONDS |
For example 20 ms in scheduler ticks might be written as:
This should only be used with constant values as the calculation is done using floating point. For constant values the compiler will do the calculation at compile time.
For non constant value use the following formula:
The parentheses are important because otherwise the division might be done first which will lead to wrong results.


Welcome to Hoodie Camp!
We created this place to welcome new and existing Hoodie contributors and to help maintainers keep an overview.
Code team
Moin! I’m Charlie the Dev Beaver.
I love clean code and a great developer experience.
- No issues right now, check back later!
Design team
¿Qué tal? I’m the Design Alpaca. I care about accessability and ease of use of our websites and apps.
- No issues right now, check back later!
Docs team
Docs docs docs! I’m the Docs Chicken and I make sure that all our code is well documented.
Editorial team
Salut! We have lots of good stories here at Hoodie, I love to share them!
- No issues right now, check back later!


index
Expresso is a JavaScript TDD framework written for nodejs. Expresso is extremely fast, and is packed with features such as additional assertion methods, code coverage reporting, CI support, and more.
assert.eql()
alias of assert.deepEqual()
assert.response()
http response utilityassert.includes()
assert.isNull()
assert.isUndefined()
assert.isNotNull()
assert.isDefined()
assert.match()
assert.length()
To install both expresso and node-jscoverage run the command below, which will first compile node-jscoverage:
$ make install
To install expresso alone without coverage reporting run:
$ make install-expresso
Install via npm:
$ npm install expresso
To define tests we simply export several functions:
exports['test String#length'] = function(){
assert.equal(6, 'foobar'.length);
};
Alternatively for large numbers of tests you may want to export your own object containing the tests, however this is essentially the as above:
module.exports = {
'test String#length': function(){
assert.equal(6, 'foobar'.length);
}
};
If you prefer not to use quoted keys:
exports.testsStringLength = function(){
assert.equal(6, 'foobar'.length);
};
The argument passed to each callback is beforeExit, which is typically used to assert that callbacks have been invoked.
exports.testAsync = function(beforeExit){
var n = 0;
setTimeout(function(){
++n;
assert.ok(true);
}, 200);
setTimeout(function(){
++n;
assert.ok(true);
}, 200);
beforeExit(function(){
assert.equal(2, n, 'Ensure both timeouts are called');
});
};
Asserts that the given val is null.
assert.isNull(null);
Asserts that the given val is not null.
assert.isNotNull(undefined);
assert.isNotNull(false);
Asserts that the given val is undefined.
assert.isUndefined(undefined);
Asserts that the given val is not undefined.
assert.isDefined(null);
assert.isDefined(false);
Asserts that the given str matches regexp.
assert.match('foobar', /^foo(bar)?/);
assert.match('foo', /^foo(bar)?/);
Assert that the given val has a length of n.
assert.length([1,2,3], 3);
assert.length('foo', 3);
Assert that the given obj is typeof type.
assert.type(3, 'number');
Assert that object b is equal to object a. This is an alias for the core assert.deepEqual() method which does complex comparisons, opposed to assert.equal() which uses ==.
assert.eql('foo', 'foo');
assert.eql([1,2], [1,2]);
assert.eql({ foo: 'bar' }, { foo: 'bar' });
Assert that obj is within val. This method supports Array_s and Strings_s.
assert.includes([1,2,3], 3);
assert.includes('foobar', 'foo');
assert.includes('foobar', 'bar');
Performs assertions on the given server, which should not call listen(), as this is handled internally by expresso and the server is killed after all responses have completed. This method works with any http.Server instance, so Connect and Express servers will work as well.
The req object may contain:
The res object may be a callback function which receives the response for assertions, or an object which is then used to perform several assertions on the response with the following properties:
When providing res you may then also pass a callback function as the fourth argument for additional assertions.
Below are some examples:
assert.response(server, {
url: '/', timeout: 500
}, {
body: 'foobar'
});
assert.response(server, {
url: '/',
method: 'GET'
},{
body: '{"name":"tj"}',
status: 200,
headers: {
'Content-Type': 'application/json; charset=utf8',
'X-Foo': 'bar'
}
});
assert.response(server, {
url: '/foo',
method: 'POST',
data: 'bar baz'
},{
body: '/foo bar baz',
status: 200
}, 'Test POST');
assert.response(server, {
url: '/foo',
method: 'POST',
data: 'bar baz'
},{
body: '/foo bar baz',
status: 200
}, function(res){
// All done, do some more tests if needed
});
assert.response(server, {
url: '/'
}, function(res){
assert.ok(res.body.indexOf('tj') >= 0, 'Test assert.response() callback');
});
To run a single test suite (file) run:
$ expresso test/a.test.js
To run several suites we may simply append another:
$ expresso test/a.test.js test/b.test.js
We can also pass a whitelist of tests to run within all suites:
$ expresso --only "foo()" --only "bar()"
Or several with one call:
$ expresso --only "foo(), bar()"
Globbing is of course possible as well:
$ expresso test/*
When expresso is called without any files, test/* is the default, so the following is equivalent to the command above:
$ expresso
If you wish to unshift a path to require.paths
before
running tests, you may use the -I
or --include
flag.
$ expresso --include lib test/*
The previous example is typically what I would recommend, since expresso supports test coverage via node-jscoverage (bundled with expresso), so you will need to expose an instrumented version of you library.
To instrument your library, simply run node-jscoverage, passing the src and dest directories:
$ node-jscoverage lib lib-cov
Now we can run our tests again, using the lib-cov directory that has been instrumented with coverage statements:
$ expresso -I lib-cov test/*
The output will look similar to below, depending on your test coverage of course :)
To make this process easier expresso has the -c or --cov which essentially does the same as the two commands above. The following two commands will run the same tests, however one will auto-instrument, and unshift lib-cov, and the other will run tests normally:
$ expresso -I lib test/*
$ expresso -I lib --cov test/*
Currently coverage is bound to the lib directory, however in the
future --cov
will most likely accept a path.
Sometimes it is useful to postpone running of tests until a callback or event has fired, currently the exports.foo = function(){}; syntax is supported for this:
setTimeout(function(){
exports['test async exports'] = function(){
assert.ok('wahoo');
};
}, 100);


Pat’s Salmon Cookies Data Output
Cookie Output Table
Add a new Store Location
Name of New Store/Location
Minimum Expected Customers per hour
Maximum Expected Customers per hour
Average Amount of Cookies Expected to be Purchased by Each Customer
Submit


Title: User_Selected_a_Cloud_on_Site_Seasonly
Last Updated: 2011-12-06 12:54
Json file:
User_Selected_a_Cloud_on_Site_Seasonly.json


Try the autocompleter!

Click me and submit to the dark side!
Need some
suggestions?
Loading...


account_circle
vpn_key
Remember Me
Forgot Password?
×
Username and Password does not match any user
×
Logged out successfully
×
Reset!
Password successfully reset!
×
Sent!
Password reset link has been sent successfully to your email!
Login


A fun, productive, and simple functional language that compiles to JavaScript.
intro | running | types | built-ins | standard library | using eth for a project | developing
intro
eth is a small in surface, small in code, easy to master, easy to adopt, functional language that will bring productivity and joy to your day programming.
simple
I tries really hard to have a unified interface, and a small amount of primitives keeping JavaScript's awesome core and avoid all the new reserved words and doubtedly useful features recent versions of JavaScript are rapidly adding.
close to JavaScript
eth remains very close to JavaScript, except for the lispyier syntax primitives are almost all written the same way, it's compatible with the whole JS exosystem, and it support all of ES5 features so, we could bet you wont feel lost when writing your first bits of eth code.
let(http require("http"))
let(hostname "<IP_ADDRESS>")
let(port 3000)
let(server http.createServer(fn(req res {
=(res.statusCode 200)
res.setHeader("Content-Type" "text/plain")
res.end("Hello World\n")
})))
server.listen(port hostname fn(
print(string("Server running at http://" hostname ":" port "/"))
))
running
You'll want to start by installing eth
using npm
:
npm install --global eth
There a repl you can start with:
$ eth repl
eth> +(3 5)
8
eth>
You can compile files to JavaScript using:
$ eth <file.eth
// ... eth prelude ...
sum(3, 5);
Or run them right away using (for production use it's better to compile & run with node
):
$ eth eval file.eth
8
In summary:
Usage: eth [command] [arguments]
Commands:
h, help prints this message
v, version prints eth's version
r, repl starts the repl
e, eval runs given file or code
b, build builds the given file
eth also works using stdin & stdout like so: eth <app.eth >app.js
Documentation can be found at http://eth-lang.com
language types
| name | example | description |
|---|---|---|
| nil | nil |
translates to undefined
|
| boolean | true |
same as JS booleans |
| number | 1.23 |
same as JS numbers |
| string | "xyz" |
same as JS strings |
| keyword | :xyz |
similar to ruby keywords, translates to a string |
| symbol | x |
translates to the symbol itself but supports special characters disallowed in JS |
| array | [1 2 3] |
same as JS arrays, but, you drop the commas |
| object | {:a 1 :b 2} |
same as JS objects, but, you drop the commas and colons |
language built-ins
get -> a[b]
set -> a = b
let -> var a = b
delete -> delete a.b
fn fn(a b {+(a b)}) -> function (a, b) { return a + b; }
cond cond(==(a b) a :else b) -> if (a == b) { return a } else { return b }
loop -> TODO use recursion!
package -> TODO use set(module.exports { ... })
import -> TODO use let(fs require("fs"))
standard library
The standard library is, at it's core, composed of all the functions in Ramda.js.
ramda
is a really neat library packed with small utility functions that all have a well designed
functional api.
Similar to lodash
and underscore
you might say but there is a fundamental difference in how ramda
orders the arguments it's functions take that makes it especially suitable for currying, composing
and functional programming in general.
If you are interested in functional programming and using eth
I then strongly encourage you pass by
ramda's awesome documentation and read the introductory post
Why Ramda?.
In addition to the functions from ramda
, eth
defined a few more useful function like to-json
,
print
, assert
and more. They are all listed below.
print assert
toJson fromJson
string type isOfType
isOdd isEven
regexp regexpMatch regexpFind regexpReplace
getIn setIn updateIn
using eth for your next project
browser
Eth compiles down to plain JavaScript so you could simply run eth <app.eth >app.js
and load
app.js
in a browser but that only hic is that you won't have access to the nice import
statements
any more.
To be able to use import
s (really require
s) you need to use a module loader / system to bundle
your code for browsers. This implies that there needs to be an integration written for the tool you
are going to choose.
For Browserify users there is no eth
integration yet but if you are up for it this soloify
project should be a good example to look at.
If you are using webpack you can install the eth-loader
package and use it like so:
// webpack.config.js
module.exports = {
entry: './src/app.eth',
output: {path: './build', filename: 'app.js'},
module: {
loaders: [{test: /\.eth$/, loader: 'eth-loader'}]
}
};
node
The story here is similar that that of CoffeeScript or TypeScript, you have mainly two option:
compiling all files and running those with node
or using node.js require.extensions
to register
a handler for files with a specific extension, .eth
in our case (this is clearly not production
worthy).
Option 1: Compiling and running
Here, a simple Makefile
that looks like the following can come in super handy:
ETH := node_modules/.bin/eth
FILES = models.js routes.js server.js
TEST_FILES = test/models.js test/routes.js
default: run
%.js: %.eth
$(ETH) <$< >$@
build: $(FILES) $(TEST_FILES)
run: build
node server.js
test: build
node -r ./test/models.js ./test/routes.js
clean:
@rm -rf *.js
@rm -rf test/*.js
Option 2: Require extension
This version of getting .eth
files to run on node.js is by far the easiest, it consists in having
a .js
file the simply requires eth/register
followed by your server.eth
, from that point on
all require
s resolving to .eth
file will get compiled first, then ran.
// bootstrap.js
require('eth/register');
require('./server');
library
You will probably want to have two directories, say src
for .eth
source files and a lib
or
build
folder for compiled javascript.
That way people consuming your library don't even need to know it is written in eth
and still use
it. To get there you'll simply have to make sure that you build all necessary .js
files before
commiting changes and have a line that looks like "main": "build/index.js"
in your package.json
.
developing
The compiler for the language is all in eth.js
and is still way under 1000 lines.
The repl/cli tool is implemented in bin/eth
.
The standard library is written in eth
and is located in the core.js
file.
To run the test suite simply run:
make test
license
MIT, see license
file.


To Do List
{{(todos | filter: {complete: 'false'}).length}}
Action:
Location:
Home
Office
Mall
Submit
#
Action
Done
{{$index + 1}}
{{item.action}}
Name:
Email:
{{getError(userForm.email.$error)}}
I agree to terms and conditions
Submit
This is a checkbox
Model Value: {{inputValue}}
Select an Action:
(Pick One)
Selected: {{selectValue || 'None'}}
Message: {{message}}
Valid: {{userForm.$valid}}
{{userForm.$valid}}


This site is for you guitar players out there. Feel free to form your own communities and discussion topics related to all rock genres.
Strat Talk is a great site for Fender enthusiasts to engage in meaningful conversation with like minded individuals.
Some of the elements unfamiliar to me are:
Elements that are familiar to me include:
What is great about Strat Talk is that it provides a very organized format for a blog site. All current/hot discussion posts are listed directly on the homepage. Navigation is very easy and effortless and is definitely user friendly. The element I believe could be improved is the sites images, adds, and format. It just seems to be a slight bit outdated and could use some revamping for a more modern audience.


_gal The algal solution had strong antifungal properties and was spun in a centrifugal machine to separate the cells from the liquid.[G|D] The conjugal couple lived a frugal life and took precautions to avoid fungal infections.[G|D] The gal had an illegal stash of madrigals hidden in her home.[G|D] The prodigal son hired a paralegal to help him reclaim his regal inheritance.[G|D]


Random Processing stereo Images
Your Image
Filtered Image(Press F5 to Refresh:))
If you Like Curren Option Just Save It


Download This Plugin
Back To jQueryScript.Net
jQuery dsCountDown Examples
Themes
Default Theme
Black Theme
Red Theme
Flat Theme
Custom Theme (Not Styled)
Language
Server Time (PHP Script)
Use server time for the count down, don't care about client time.


Limited Time - Online and in-store
Countdown to Summer
$5 Small Jar Candles
$4 Concentrated Room Sprays
$3 Fragrance Spheres™
$2 Car Jar® Air Fresheners
$1 Samplers® Votive Candles and Tarts® Wax Melts
To buy now, copy and paste:
http://links.mkt1917.com/ctt?kn=28&ms=MTI5NjY5MzkS1&r=Mzc1MTMwMDUwMTIS1&b=2&j=NzQzNTg1NDYwS0&mt=1&rt=0
into your browser
To find a store, copy and paste:
http://links.mkt1917.com/ctt?kn=13&ms=MTI5NjY5MzkS1&r=Mzc1MTMwMDUwMTIS1&b=2&j=NzQzNTg1NDYwS0&mt=1&rt=0
into your browser


DETEX(1L) DETEX(1L) NAME detex - a filter to strip TeX commands from a .tex file. SYNOPSIS detex [ -clnstw ] [ -e environment-list ] [ filename[.tex] ... ] DESCRIPTION Detex (Version 2.6) reads each file in sequence, removes all comments and TeX control sequences and writes the remainder on the standard output. All text in math mode and display mode is removed. By default, detex follows \input commands. If a file cannot be opened, a warning message is printed and the command is ignored. If the -n option is used, no \input or \include commands will be processed. This allows single file processing. If no input file is given on the command line, detex reads from standard input. If the magic sequence ``\begin{document}'' appears in the text, detex assumes it is dealing with LaTeX source and detex recognizes additional constructs used in LaTeX. These include the \include and \includeonly commands. The -l option can be used to force LaTeX mode and the -t option can be used to force TeX mode regardless of input content. Text in various environment modes of LaTeX is ignored. The default modes are array, eqnarray, equation, figure, mathmatica, picture, table and verbatim. The -e option can be used to specify a comma separated envi‐ ronment-list of environments to ignore. The list replaces the defaults so specifying an empty list effectively causes no environments to be ignored. The -c option can be used in LaTeX mode to have detex echo the arguments to \cite, \ref, and \pageref macros. This can be useful when sending the output to a style checker. Detex assumes the standard character classes are being used for TeX. Detex allows white space between control sequences and magic characters like `{' when recognizing things like LaTeX environments. If the -w flag is given, the output is a word list, one `word' (string of two or more letters and apostrophes beginning with a letter) per line, and all other characters ignored. Without -w the output follows the original, with the deletions mentioned above. Newline characters are preserved where possible so that the lines of output match the input as closely as possible. The TEXINPUTS environment variable is used to find \input and \include files. Like TeX, it interprets a leading or trailing `:' as the default TEXINPUTS. It does not support the `//' directory expansion magic sequence. Detex now handles the basic TeX ligatures as a special case, replacing the ligatures with acceptable charater substitutes. This eliminates spelling errors introduced by merely removing them. The ligatures are \aa, \ae, \oe, \ss, \o, \l (and their upper-case equivalents). The spe‐ cial "dotless" characters \i and \j are also replaced with i and j respectively. Note that previous versions of detex would replace control sequences with a space character to prevent words from running together. However, this caused accents in the middle of words to break words, generating "spell‐ ing errors" that were not desirable. Therefore, the new version merely removes these accents. The old functionality can be essentially dupli‐ cated by using the -s option. SEE ALSO tex(1L) DIAGNOSTICS Nesting of \input is allowed but the number of opened files must not exceed the system's limit on the number of simultaneously opened files. Detex ignores unrecognized option characters after printing a warning message. AUTHOR Daniel Trinkle, Computer Science Department, Purdue University BUGS Detex is not a complete TeX interpreter, so it can be confused by some constructs. Most errors result in too much rather than too little out‐ put. Running LaTeX source without a ``\begin{document}'' through detex may produce errors. Suggestions for improvements are (mildly) encouraged. Purdue University 12 August 1993 DETEX(1L)


- What are git and github
- How they work
- How can I use them
“Git (/ɡɪt/) is a distributed revision control system with an emphasis on speed, data integrity, and support for distributed, non-linear workflows.”
“Revision control, also known as version control and source control, is the management of changes to documents, computer programs, large web sites, and other collections of information.”
clear, uh?
Why should I use version control?
“An elegant weapon for a more civilized age.”
Look, it's not useful if I
- Do not have other people working on the code.
- Do not plan on letting others have the code.
- Isn't it an overhead?
Well, have you ever
- made a change to code, realised it was a mistake and wanted to revert back?
- lost code or had a backup that was too old?
- had to maintain multiple versions of a product?
And if you wonder to
- see the difference between two (or more) versions of your code?
- prove that a particular change broke or fixed a piece of code?
- review the history of some code?
Or even
- submit a change to someone else's code?
- share your code, or let other people work on your code?
- see how much work is being done, and where, when and by whom?
And, last but not least
- wanted to experiment with a new feature without interfering with working code?
Desing Goals
- Speed
- Simple Design
- Strong support for thousands of parallel branches
- Fully distributed
- Able to handle larges projects like Linux kernel effectively
- Ensure integrity
Git is a filesystem
Git thinks of its data more like a set of snapshots of a mini filesystem.
Git has integrity
- Everything is checksummed
- References are SHA-1
986da33f0edea8f13b8dee427262ffd1bce0a4c4
Git doesn't delete
- generally only adds data
- if you mess up, you can usually recover your stuff
- not for everyone, though
Three states
- Modified
- Staged
- Committed
- Pushed?
- web-based Git repository hosting service
- offers all of the distributed SCM functionalities of Git
- adds new features
New features
- web-based graphical interface
- desktop & mobile integration
- access control
- pull requests
- and more (wikis, task management, bug tracking, etc.)
Linux
Debian
$ aptitude install git
Ubuntu
$ apt-get install git
Centos
$ yum install git
Arch
$ pacman -S git
OS X
$ brew install git
Also developer tools should be ok...
Identity
$ git config --global user.name "Peter Parker"
$ git config --global user.email<EMAIL_ADDRESS>Editor
$ git config --global core.editor nano
Colors
$ git config --global color.ui true
Configurations are in ~/.gitconfig
Initizialize your project
$ git init
Or clone it
$ git clone https://github.com/andou/github-for-dummies.git
Decide what is relevant
$ git add file1 file2 ...
$ git commit
What did I just modify
$ git diff
I've screwed everything up....
$ git reset
sample
.DS_Store
*.log
/build/
/doc/[abc]*.txt
.sass-cache
- Blank lines or lines starting with # are ignored
- End pattern with slash (/) to specify a directory
- Negate pattern with exclamation point (!)
- Other clones of the same repo
- Can be more than one
- There are default remotes for push and pull
- Github is a remote
$ git remote -v
origin https://github.com/andou/github-for-dummies.git (fetch)
origin https://github.com/andou/github-for-dummies.git (push)
Push to remote
$ git push <remote> <branch>
Pull from remote
$ git pull <remote> <branch>
- specify important points in history
- tipically release points
Lightweight tags
$ git tag v0.0.1
Annotated tags
$ git tag -a v0.0.1 -m 'this is my tag'
- are "pointers" to commit
- identify streams of development
- they can diverge from each other
- they can be merged
Diverging branches
Merged branches
Merging
- There are different auto-merge strategies
- If it fails, you'll have to fix by hand
- Mark conflicts as resolved and trigger a merge commit
Create new branch
$ git branch iss53
$ git checkout -b iss53 master
Switch Branch
$ git checkout iss53
Delete Branch
$ git branch -d iss53
Move changes to a separate "stash".
$ git stash save
$ git stash list
$ git stash apply
Progressive stability
Topic branches
Legal
License
Attribution


Zongchen Teng
Project Portfolio Lab1
Watch Out For Ice
Projects
Design Thinking
Needfinding
Prototyping
...


Mary Hunter Austin
American Writer, Poet, and Critic
Photo Mary Austin (1885)
Things that Mary Hunter Austin wrote during her life (September 9, 1868 – August 13, 1934):
The Land of Little Rain (1903), an account of the California Desert.
The Basket Woman (1904), a book of Indian myths and fanciful tales for children.
Isidro (book) (1905), a romance of Mission days.
Go to this Wiki link for more information:
Mary Austin


Pope Francis arrives in Japan to promote anti-nuclear message
TOKYO (Reuters) - Pope Francis arrived on Saturday in Japan, the second leg of a week-long Asian trip whose main aim is to bring an anti-nuclear message to Nagasaki and Hiroshima, the world’s only cities to suffer atomic bombing in wartime.
Francis, a determined anti-nuclear campaigner who will read a message on nuclear weapons in Nagasaki, will also meet survivors of the March 11, 2011 nuclear meltdown at Fukushima, the world’s worst nuclear disaster since Chernobyl in 1986.
The pope touched down in Tokyo after flying from Thailand for a four-day visit that will be the first in 38 years and only the second in history.
Another goal of his visit is to encourage the Catholic community in Japan, where just about 1 percent of the population identifies as Christian, about half of them Catholic.
He will say two Masses, one in Nagasaki and one in Tokyo, as well as meeting Japanese officials and Emperor Naruhito.


Dockerizing a React App
Docker is a containerization tool used to speed up the development and deployment processes. If you’re working with microservices, Docker makes it much easier to link together small, independent services. It also helps to eliminate environment-specific bugs since you can replicate your production environment locally.
This tutorial demonstrates how to Dockerize a React app using the Create React App generator. We’ll specifically focus on-
- Setting up a development environment with code hot-reloading
- Configuring a production-ready image using multistage builds
Updates:
- April 2020:
- Updated to the latest versions of Docker, Node, React, and Nginx.
- Removed the Docker Machine section.
- Updated the
docker run
commands to account for changes inreact-scripts
v3.4.1.
- May 2019:
- Updated to the latest versions of Docker, Node, React, and Nginx.
- Added explanations for various Docker commands and flags.
- Added a number of notes based on reader comments and feedback.
- Feb 2018:
- Updated to the latest versions of Node, React, and Nginx.
- Added an anonymous volume.
- Detailed how to configure Nginx to work properly with React Router.
- Added a production build section that uses multistage Docker builds.
We will be using:
- Docker v19.03.8.
- Create React App v3.4.1
- Node v13.12.0
Contents
Project Setup
Install Create React App globally:
$ npm install -g<EMAIL_ADDRESS>Generate a new app:
$ npm init react-app sample --use-npm
$ cd sample
Docker
Add a Dockerfile to the project root:
# pull official base image
FROM node:13.12.0-alpine
# set working directory
WORKDIR /app
# add `/app/node_modules/.bin` to $PATH
ENV PATH /app/node_modules/.bin:$PATH
# install app dependencies
COPY package.json ./
COPY package-lock.json ./
RUN npm install --silent
RUN npm install<EMAIL_ADDRESS>-g --silent
# add app
COPY . ./
# start app
CMD ["npm", "start"]
Silencing the NPM output, via
--silent
, is a personal choice. It’s often frowned upon, though, since it can swallow errors.
Add a .dockerignore:
node_modules
build
.dockerignore
Dockerfile
Dockerfile.prod
This will speed up the Docker build process as our local dependencies inside the “node_modules” directory will not be sent to the Docker daemon.
Build and tag the Docker image:
$ docker build -t sample:dev .
Then, spin up the container once the build is done:
$ docker run \
-it \
--rm \
-v ${PWD}:/app \
-v /app/node_modules \
-p 3001:3000 \
-e CHOKIDAR_USEPOLLING=true \
sample:dev
If you run into an
"ENOENT: no such file or directory, open '/app/package.json".
error, you may need to add an additional volume:-v /app/package.json
.
What’s happening here?
- The docker run command creates and runs a new container instance from the image we just created.
-
-it
starts the container in interactive mode. Why is this necessary? As of version 3.4.1,react-scripts
exits after start-up (unless CI mode is specified) which will cause the container to exit. Thus the need for interactive mode. --rm
removes the container and volumes after the container exits.-
-v ${PWD}:/app
mounts the code into the container at “/app”.{PWD}
may not work on Windows. See this Stack Overflow question for more info. - Since we want to use the container version of the “node_modules” folder, we configured another volume:
-v /app/node_modules
. You should now be able to remove the local “node_modules” flavor. -
-p 3001:3000
exposes port 3000 to other Docker containers on the same network (for inter-container communication) and port 3001 to the host.For more, review this Stack Overflow question.
- Finally,
-e CHOKIDAR_USEPOLLING=true
enables a polling mechanism via chokidar (which wrapsfs.watch
,fs.watchFile
, andfsevents
) so that hot-reloading will work.
Open your browser to http://localhost:3001/ and you should see the app. Try making a change to the App
component within your code editor. You should see the app hot-reload. Kill the server once done.

Want to use Docker Compose? Add a docker-compose.yml file to the project root:
version: '3.7'
services:
sample:
container_name: sample
build:
context: .
dockerfile: Dockerfile
volumes:
- '.:/app'
- '/app/node_modules'
ports:
- 3001:3000
environment:
- CHOKIDAR_USEPOLLING=true
Take note of the volumes. Without the anonymous volume ('/app/node_modules'
), the node_modules directory would be overwritten by the mounting of the host directory at runtime. In other words, this would happen:
- Build - The
node_modules
directory is created in the image. - Run - The current directory is mounted into the container, overwriting the
node_modules
that were installed during the build.
Build the image and fire up the container:
$ docker-compose up -d --build
Ensure the app is running in the browser and test hot-reloading again. Bring down the container before moving on:
$ docker-compose stop
Windows Users: Having problems getting the volumes to work properly? Review the following resources:
You also may need to add
COMPOSE_CONVERT_WINDOWS_PATHS=1
to the environment portion of your Docker Compose file. Review the Declare default environment variables in file guide for more info.
Production
Let’s create a separate Dockerfile for use in production called Dockerfile.prod:
# build environment
FROM node:13.12.0-alpine as build
WORKDIR /app
ENV PATH /app/node_modules/.bin:$PATH
COPY package.json ./
COPY package-lock.json ./
RUN npm ci --silent
RUN npm install<EMAIL_ADDRESS>-g --silent
COPY . ./
RUN npm run build
# production environment
FROM nginx:stable-alpine
COPY --from=build /app/build /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]
Here, we take advantage of the multistage build pattern to create a temporary image used for building the artifact – the production-ready React static files – that is then copied over to the production image. The temporary build image is discarded along with the original files and folders associated with the image. This produces a lean, production-ready image.
Check out the Builder pattern vs. Multi-stage builds in Docker blog post for more info on multistage builds.
Using the production Dockerfile, build and tag the Docker image:
$ docker build -f Dockerfile.prod -t sample:prod .
Spin up the container:
$ docker run -it --rm -p 1337:80 sample:prod
Navigate to http://localhost:1337/ in your browser to view the app.
Test with a new Docker Compose file as well called docker-compose.prod.yml:
version: '3.7'
services:
sample-prod:
container_name: sample-prod
build:
context: .
dockerfile: Dockerfile.prod
ports:
- '1337:80'
Fire up the container:
$ docker-compose -f docker-compose.prod.yml up -d --build
Test it out once more in your browser.
React Router and Nginx
If you’re using React Router, then you’ll need to change the default Nginx config at build time:
COPY --from=build /app/build /usr/share/nginx/html
Add the change to Dockerfile.prod:
# build environment
FROM node:13.12.0-alpine as build
WORKDIR /app
ENV PATH /app/node_modules/.bin:$PATH
COPY package.json ./
COPY package-lock.json ./
RUN npm ci --silent
RUN npm install<EMAIL_ADDRESS>-g --silent
COPY . ./
RUN npm run build
# production environment
FROM nginx:stable-alpine
COPY --from=build /app/build /usr/share/nginx/html
# new
COPY nginx/nginx.conf /etc/nginx/conf.d/default.conf
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]
Create the following folder along with a nginx.conf file:
└── nginx
└── nginx.conf
nginx.conf:
server {
listen 80;
location / {
root /usr/share/nginx/html;
index index.html index.htm;
try_files $uri $uri/ /index.html;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/share/nginx/html;
}
}
Next Steps
With that, you should now be able to add React to a larger Docker-powered project for both development and production environments. If you’d like to learn more about working with React and Docker along with building and testing microservices, check out the Microservices with Docker, Flask, and React course bundle at TestDriven.io.


{include file='web/display/head.html'}
Home
{include file='web/display/head/head.html'}
Home
»
Account
{include file='web/display/account/account_left.html'}
HollenMok
Settings
Edit Avatar
Orders
10
Order Goods
Order NO.
Consignee
Order Account
Order Time
Order Status
Operating
10000001
HollenMok
US$35.99
Mar. 19 2016
Payment Confirmed
View
10000002
HollenMok
US$45.99
Mar. 20 2016
Payment Confirmed
View
{include file='web/display/foot/foot.html'} {include file='web/display/home/bottom.html'}


| [
Graph Home ] [ Set-Up
] [ Tutorials ] [
Documentation
] [
Buy Now ] [
Support ] |
2D/3D
Area Graph for PHP
Documentation
- Full Parameter Reference
|
|
|
|
There are many configurable options
for the graphing software. This section describes
each parameter and it's effect in detail.
With the exception of 2 parameters,
all of the following are optional and if not supplied
the graph will automatically calculate the values.
The only 2
parameters which must be supplied in all cases
are width and height.
|
| General Graph
Properties |
|
| Parameter Name |
Range of Values |
Example |
| width |
integer value
Specifies the width in pixels |
width: 300 |
| height |
integer value
Specifies the height in pixels |
height: 400 |
| ndecplaces |
integer value
Specifies the number of decimal places to use when displaying values |
ndecplaces: 2 |
| thousandseparator |
Any character symbol. |
thousandseparator: , |
| backgroundcolor |
Color definition (see Colors»)
general background color of the graph image |
backgroundcolor: white |
| connectinglines |
True or False
determines whether points should be connected or not |
connectinglines: true |
| displayvalues |
True or False
specifies whether actual values should be displayed at the top of each point |
displayvalues: false |
| bgimage |
URL to an Image file
specifies an image to used as the background |
bgimage: brimage.gif |
«back to top
|
|
| Grid Properties |
| Parameter Name |
Range of Values |
Example |
| grid |
True or False
specifies whether to draw grid lines or not |
grid: true |
| axis |
True or False
specifies whether to draw axis lines or not |
axis: |
| nrows |
integer value
number of grid rows |
nrows: 10 |
| hspace |
integer value
space in pixels of each grid column |
hspace: 30 |
| vspace |
integer value
space in pixels of each grid row |
vspace: 30 |
| gridstyle |
valid values are:-
solid
dashed
dotted
long dashed
dotted dashed
specifies the line style of the grid lines
|
gridstyle: dotted |
| gridcolor |
Color definition (see Colors»)
Grid line color |
gridcolor: #888888 |
| axiscolor |
Color definition (see Colors»)
Axis line color |
axiscolor: #000000 |
| floorcolor |
Color definition (see Colors»)
If 3D is on then this specifies the color of the x-axis floor |
floorcolor: #555599 |
| gridbgimage |
URL to an Image file
specified an image to used as the grid background |
gridbgimage: brimage.gif |
| gridbgcolor |
Color definition (see Colors»)
the background color of the grid area |
gridbgcolor: light grey |
| gridposition |
an x,y, position
specifies the position of the bottom left of the grid |
gridposition: 30,275 |
| gridlineh |
True or False
specifies whether to draw horizontal grid lines or not |
gridlineh: false |
| gridlinev |
True or False
specifies whether to draw vertical grid lines or not |
gridlinev: false |
| gridbgcolor2 |
Color definition (see Colors»)
specifies a second background color of the grid area. If this parameter is specified then grid rows are
colored alternating between this color and gridbgcolor |
gridbgcolor2: grey |
«back to top
|
|
| Scale Properties |
|
AutoScale function.
If any of the following scale parameters are not supplied then the graphing software will automatically calculate
the scale from the data supplied. Therefore if you would like the scale to be calculated automatically then
simply ommit the following parameters from the configuration.
| Parameter Name |
Range of Values |
Example |
| chartscale |
Numeric Value
specifies the value the each grid row is to represent on the left hand axis |
chartscale: 1000 |
| chartstarty |
Numeric Value
specifies the starting value fot the left hand axis |
chartstarty: 0 |
«back to top
|
|
| 3D Properties |
| Parameter
Name |
Range
of Values |
Example |
| 3d |
True or False
determines whether the graph should
be 3D or 2D |
3d: true |
| depth3d |
Integer Value
specifies the depth in pixels
of the 3D effect |
depth3d:
20 |
«back to top
|
|
| Legend Properties |
| Parameter
Name |
Range
of Values |
Example |
| legend |
True or False
determines whether the graph legend
should be drawn or not |
legend:
true |
| legendstyle |
horizontal or vertical
specifies whether the legend should
be horizontal or vertical |
legendstyle:
horizontal |
| legendbgcolor |
Color definition
(see
Colors»)
background color of the legend
area |
legendbgcolor:
white |
| legendbordercolor |
Color definition
(see
Colors»)
border color of the legend |
legendbordercolor:
light blue |
| legendtextcolor |
Color definition
(see
Colors»)
text color of the legend |
legendtextcolor:
black |
| legendtitle |
Text
legend title. leave blank if no
title required. |
legendtitle:
The Legned |
| legendposition |
X,Y position
position of the legend. |
legendposition:
50,50 |
| legendfont |
Font Definition :-
small
medium
medium bold
large
large bold
|
legendfont:
medium |
«back to top
|
|
| X-Axis Labels |
| Parameter
Name |
Range
of Values |
Example |
| xlabelorientation |
can be one of
horizontal
vertical
up angle
downangle
specifies the orientation of
the x-axis labels
|
xlabelorientation:
up angle |
| xlabelypos |
Integer value
specifies the y position of the
x-axis labels |
xlabelypos:
250 |
| xlabeloffset |
Integer Value
species the pixel y offset of
every second label. Useful when
a horizontal orientaiton is specified |
xlabeloffset:
15 |
| xfont |
Font Definition :-
small
medium
medium bold
large
large bold
|
xfont:
medium bold |
| xlabelcolor |
Color definition
(see
Colors»)
x-axis label text color |
xlabelcolor:
blue |
| xlabels |
List of labels seperated
by | character. |
xlabels:
Jan|Feb|Mar|Apr|May| |
«back to top
|
|
| Y-Axis Labels |
| Parameter Name |
Range of Values |
Example |
| ylables |
True or False
determines whether y-axis labels should be drawn or not |
ylables: true |
| yfont |
Font Definition :-
small
medium
medium bold
large
large bold
|
yfont: medium |
| ylabelcolor |
Color definition (see Colors»)
left hand y-axis label text color |
ylabelcolor: black |
| ylabelpre |
Character or Text
leading character or text for each left hand label |
ylabelpre: $ |
| ylabelpost |
Character or Text
trailing character or text for each left hand label |
ylabelpost: kph |
«back to top
|
|
| Graph Titles |
|
| Parameter Name |
Range of Values |
Example |
| titletext |
Text
Main graph title |
titletext: Graph Title |
| titlefont |
Font Definition :-
small
medium
medium bold
large
large bold
|
titlefont: large bold |
| titlecolor |
Color definition (see Colors»)
text color |
titlecolor: purple |
| titleposition |
X,Y Position
position of the title |
titleposition: 100,20 |
|
|
|
| xtitletext |
Text
x-axis title |
xtitletext: X Title |
| xtitlefont |
Font Definition :-
small
medium
medium bold
large
large bold
|
xtitlefont: medium bold |
| xtitlecolor |
Color definition (see Colors»)
text color |
xtitlecolor: blue |
| xtitleposition |
X,Y Position
position of the x-axis title |
xtitleposition: 150,350 |
|
|
|
| ytitletext |
Text
left hand y-axis title |
ytitletext: Left Y Title |
| ytitlefont |
Font Definition :-
small
medium
medium bold
large
large bold
|
ytitlefont: medium bold |
| ytitlecolor |
Color definition (see Colors»)
text color |
ytitlecolor: dark green |
| ytitleposition |
X,Y Position
position of the left hand y-axis title |
ytitleposition: 10,150 |
«back to top
|
|
| Series Specifications |
|
Six parameters may be supplied for each series of data. These are:-
Area Color
Legend Text
Point Size
Point Style
Point Fill (true or false)
Line Style
Point Style - valid values are :-
- "point"
- "circle"
- "cross"
- "pluscross"
- "xcross"
- "box"
- "triangle"
- "diamond"
- "hexagon"
Line Style - valid values are:-
- "solid"
- "dashed"
- "dotted"
- "long dashed"
- "dotted dashed"
The format of the series parameter is:-
| seriesN: color | text | size | pt style | fill
| line style |
where N represents the series number
For example if there are 2 series of data with the first using the left hand scale and the second using the
right hand scale, the series parameter would be:-
series1: pink|Series One|6|triangle|true|solid|
series2: blue|Series Two|4|circle|true|dashed| |
For more further information on the color element please see Colors»
«back to top
|
|
| Target Areas |
|
Any number of horizontal target line
may be added to the chart with the
parameter "target".
The target parameter is made up of 5elements:-
value
color
text
font
line style
The format of the target line parameter
is:-
| target: value | color | text | font | line Style
| |
For more on color defintions see
Colors»
The font defintion can be one of:-
small
medium
medium bold
large
large bold
The line style can be one of:-
solid
dashed
dotted
long dashed
dotted dashed
For example to set a target line
at a value of 1000 on the chart,
| target: 1000|green|Break Even|medium|dashed| |
«back to top
|
|
| Trend Areas |
|
Any number of trend lines may be
added to the chart with the parameter
"trend".
The trend parameter is made up of 8 elements:-
start value
start column
end value
end column
color
text
font
line style
The format of the target line parameter
is:-
| trend: start value|start column|end value|end
column|color|text|font|line Style| |
For more on color defintions see
Colors»
The font defintion can be one of:-
small
medium
medium bold
large
large bold
The line style can be one of:-
solid
dashed
dotted
long dashed
dotted dashed
For example to set a trend line starting
at a value of 1000 in column 2 and
ending at a value of 1550 in column
6,
| trend: 1000|2|1550|6|green|Up Trend|medium|dashed| |
«back to top
|
|
| Free Form
Text |
|
In addition to the standard titles,
any number of lines of text may be
added to the graph using the "text"
parameter.
The text parameter is consists of
4 elements:-
text
font
color
position
The format of the text parameter
is:-
| text:
text | font | color | position
| |
For more on color defintions see
Colors»
The font defintion can be one of:-
small
medium
medium bold
large
large bold
For example if 3 lines of text were
to be added the following parameters
would be included in the configuration:-
text:
line one of text|medium|#000000|50,50|
text: line two of text|medium|#000000|50,65|
text: line three of text|medium|#000000|50,80|
|
«back to top
|
|
| Free Form
Images |
|
Any number of images may be added
to the graph using the "image"
parameter.
The image parameter is consists of
2 elements:-
URL or Filename
of an image file
position
The format of the image parameter
is:-
| image:
URL or filename | position | |
For example if an image "logo.png"
was to be drawn on the graph image
then the following parameter would
be included in the configuration:-
«back to top
|
|
|
|
|
|
| [ Graph Home ] [ Set-Up
] [ Tutorials ] [ Documentation ] [
Buy Now ] [ Support ] |
|
|


Contacts
Email
Name
Phone
Modify Content
Delete Content
First Name:
Last Name:
Email Address:
Phone Number:
Save


{% extends "page.html" %} {% block main %}
{% if failed %} The latest attempt to start your cluster {{ server_name }} has failed.
{% if failed_message %}{{ failed_message }}
{% endif %}Would you like to retry starting it? {% else %} Your cluster {{ server_name }} is not running. Would you like to start it? {% endif %}
{% endblock %} {% block start_button %} {% if failed %} Relaunch {% else %} Launch {% endif %} Cluster {{ server_name }} {% endblock %}


--- layout: page title: About news_posts: 8 ---
The 56th Annual Meeting of the Association for Computational Linguistics was held in Melbourne, Australia at the Melbourne Convention and Exhibition Centre from July 15th to 20th, 2018.
| {{ kd.date }} | {{ kd.event }} |
General Chair: Claire Cardie
Full Organising Committee List


Crossing the border with Thailand from Luang Namtha in northern Laos
by Monika Suchoszek
Finally, it was a time to cross the border with Thailand and start our adventure in the last country on our list during this trip. We knew that it’s not possible to take a bus in one go from Nong Khiaw to the border with Thailand, 400km further. Therefore, we took a minivan to Luang Namtha and from there, with the help of a travel agency, we crossed the border in one day, finally arriving in Chiang Rai in northern Thailand. More details further in the post.
Luang Namtha didn’t look like particularly interesting town but we just decided to stay there 1 day and not rush too much to the next place. We didn’t book anything in advance and after 1 hour of walk we ended up in the guesthouse, just in front of the entrance to the night market (very basic market). The next day we rented mountain bikes and cycled to the surrounding villages, making a loop of 27km around the city, see map below. We saw a local temple, Samakkhixay Stupa, people working on the fields, a school full of kids, animals running everywhere. It was very quiet, we observed everyday life of the local community and had a nice dinner afterwards at Lai’s Place. It always a nice feeling when kids are greetings us everywhere really loud and run after our bikes with their big smiles :)
There were two options for crossing the border with Thailand, do this on our own or with the help of travel agency. The first option means taking a bus to Huay Xai, then a tuk-tuk to the Friendship Bridge, crossing the bridge with another bus, another tuk-tuk to Chiang Khong, (probably spend a night there) and take a local bus to Chiang Rai. We couldn’t find the bus schedule from Chiang Khong to Chiang Rai and actually wanted to get to Chiang Rai as fast as possible. So we decided to purchase a combined ticket from one of the travel agencies. All in all it was very smooth ride, tuk-tuk drivers were waiting for us, everything was well organised, we didn’t have to wait very long between switching between different transport modes. Crossing the border itself was also very easy, no corruption, no extra fees, nice! :D
We arrived at the bus station in Chiang Rai just after 5pm. Where we were very happy to discover that the hostel we booked was located nearby be as well as a night market which turned out to be very nice place for the evening walks!
Of course if you do everything by yourself it’s likely going to be a half the price for the tickets and it might be possible to do this in one day as well if you are lucky. You would have to start with an early bus to Huay Xai at 8.30am, after around 4.5h of drive you are at your destination. We noticed the prices of some tickets, e.g. local bus from Chiang Khong to Chiang Rai was 120BTH (4$), tuk-tuk to the bridge 40BTH and bus crossing the bridge was again 40BTH. While getting on the local bus to Chiang Rai, we saw a schedule of the buses and they also operate in the afternoons.
Practical info:
- minivan to Luang Namtha from Nong Khiaw - 6.5h, 70k KIP per person
- crossing the border with Thailand with the assistance of travel agency (Gat Way Tour travel agency) - 200k KIP per person
- tuk-tuk from bus station to city center of Nong Khiaw - 15k KIP per person (8km)
- renting a mountain bike - 20k KIP per person,
- lunch/dinner - 50k-70k KIP for both of us, we recommend Lai’s Place Restaurant
- guesthouse - 60k KIP per night
Subscribe via RSS


climate change adaptation barriers management opportunities political resource support lack planning ranked participants (Fig. natural survey Change actions factors landscapes Climate Environ {border-style action results Arctic px;} related #ffffff;} address important Alaska Northern Ontario’s Transboundary conservation study funding land regions ./s--- leadership managers resources collaboration impacts local agency efforts financial landscapes, science significant Kemp Rockies addressing employee, identified implementation organizations affecting common ecological federal importance include open-ended public research responses Adaptation Glob Lemieux North barrier challenges current finding information interview need organizational particular particularly regions, specific understanding Adirondack Aylett Boreal Park influential landscapes. level opportunity px; suggest use work {font-family Adirondacks Archie Clim Cross Manage Ontario adaptation, agencies approaches challenge change, change: cited critical emerged font-size frequently human identify including increased key mentioned progress regional respondents second staff studies systems temperature ~Federal (Jantarasami (US), ./.. American Barriers Bierbaum Boreal, Political ability adaptation. appropriate capacity competing considered data deficits, different double; emphasis example, face findings fourth help higher indicate individuals invited issue northern opportunities, overcome perceived priorities private projections recognition relatively social species time translating urban uses working (e.g., ./j.gloenvcha... Adirondacks, Bulkeley Conserv New Opportunities Regional Resource Rockies, Shi WCS Wildlife able barrier, based border-color border-width collaboration, complex conducted development ecosystems forests funding, general government highly influence integrity long-term make multiple national new place regions. resources, scores solid; state terms themes threat using water wild workshop workshops {font-style {font-weight (Aylett (Biesbroek (Burch (Measham ./j.-...x Adapt Assoc Average Biggest Cambridge Conservation Differences Ecol Eisenack Ekstrom Enquist Fig. Foundation Future Lack Mitig Nordgren Plan Rocky Runhaar Sci Strateg Uittenbroek United [], according additional and/or annual article barriers, bold certain change. collaborative combined contexts contexts, courier; deficits did driving em; enable expertize global highest highlighted identifying increases insight intact international interviews lands landscape municipal nature networks number participate policies policy political, practitioners present provided pt;} ranking region region. research, review scale sharing tool types uncertainty varied


| Package | Description |
|---|---|
| org.springframework.validation |
Provides data binding and validation functionality,
for usage in business and/or UI layers.
|
| org.springframework.validation.beanvalidation |
Support classes for integrating a JSR-303 Bean Validation provider
(such as Hibernate Validator) into a Spring ApplicationContext
and in particular with Spring's data binding and validation APIs.
|
| Modifier and Type | Interface and Description |
|---|---|
interface |
SmartValidator
Extended variant of the
Validator interface, adding support for
validation 'hints'. |
| Modifier and Type | Method and Description |
|---|---|
Validator |
DataBinder.getValidator()
Return the primary Validator to apply after each binding step, if any.
|
| Modifier and Type | Method and Description |
|---|---|
List<Validator> |
DataBinder.getValidators()
Return the Validators to apply after data binding.
|
| Modifier and Type | Method and Description |
|---|---|
void |
DataBinder.addValidators(Validator... validators)
Add Validators to apply after each binding step.
|
static void |
ValidationUtils.invokeValidator(Validator validator,
Object target,
Errors errors)
|
static void |
ValidationUtils.invokeValidator(Validator validator,
Object target,
Errors errors,
Object... validationHints)
|
void |
DataBinder.replaceValidators(Validator... validators)
Replace the Validators to apply after each binding step.
|
void |
DataBinder.setValidator(Validator validator)
Set the Validator to apply after each binding step.
|
| Modifier and Type | Class and Description |
|---|---|
class |
CustomValidatorBean
Configurable bean class that exposes a specific JSR-303 Validator
through its original interface as well as through the Spring
Validator interface. |
class |
LocalValidatorFactoryBean
This is the central class for
javax.validation (JSR-303) setup in a Spring
application context: It bootstraps a javax.validation.ValidationFactory and
exposes it through the Spring Validator interface
as well as through the JSR-303 Validator interface and the
ValidatorFactory interface itself. |
class |
OptionalValidatorFactoryBean
LocalValidatorFactoryBean subclass that simply turns
Validator calls into no-ops
in case of no Bean Validation provider being available. |
class |
SpringValidatorAdapter
Adapter that takes a JSR-303
javax.validator.Validator and
exposes it as a Spring Validator
while also exposing the original JSR-303 Validator interface itself. |