This document describes the use of the NTP Project's ntp-keygen
program, that generates cryptographic data files used by the NTPv4
authentication and identity schemes.
It can generate message digest keys used in symmetric key cryptography and,
if the OpenSSL software
library has been installed, it can generate host keys, sign keys,
certificates, and identity keys and parameters used by the Autokey
public key cryptography.
The message digest keys file is generated in a
format compatible with NTPv3.
All other files are in PEM-encoded
printable ASCII format so they can be embedded as MIME attachments in
mail to other sites.
This document applies to version 4.2.7p368 of ntp-keygen
.
This program generates cryptographic data files used by the NTPv4 authentication and identity schemes. It can generate message digest keys used in symmetric key cryptography and, if the OpenSSL software library has been installed, it can generate host keys, sign keys, certificates, and identity keys and parameters used by the Autokey public key cryptography. The message digest keys file is generated in a format compatible with NTPv3. All other files are in PEM-encoded printable ASCII format so they can be embedded as MIME attachments in mail to other sites.
When used to generate message digest keys, the program produces a file containing ten pseudo-random printable ASCII strings suitable for the MD5 message digest algorithm included in the distribution. If the OpenSSL library is installed, it produces an additional ten hex-encoded random bit strings suitable for the SHA1 and other message digest algorithms. The message digest keys file must be distributed and stored using secure means beyond the scope of NTP itself. Besides the keys used for ordinary NTP associations, additional keys can be defined as passwords for the ntpq and ntpdc utility programs.
The remaining generated files are compatible with other OpenSSL applications and other Public Key Infrastructure (PKI) resources. Certificates generated by this program are compatible with extant industry practice, although some users might find the interpretation of X509v3 extension fields somewhat liberal. However, the identity keys are probably not compatible with anything other than Autokey.
Some files used by this program are encrypted using a private password.
The -p
option specifies the password for local encrypted files and the
-q
option the password for encrypted files sent to remote sites.
If no password is specified, the host name returned by the Unix
gethostname()
function, normally the DNS name of the host, is used.
The pw option of the crypto
configuration command
specifies the read password for previously encrypted local files.
This must match the local password used by this program.
If not specified, the host name is used.
Thus, if files are generated by this program without password,
they can be read back by ntpd without password, but only on the same
host.
Normally, encrypted files for each host are generated by that host and
used only by that host, although exceptions exist as noted later on
this page.
The symmetric keys file, normally called ntp.keys
, is
usually installed in /etc
.
Other files and links are usually installed
in /usr/local/etc
, which is normally in a shared filesystem in
NFS-mounted networks and cannot be changed by shared clients.
The location of the keys directory can be changed by the keysdir
configuration command in such cases.
Normally, this is in /etc
.
This program directs commentary and error messages to the standard
error stream stderr
and remote files to the standard output stream
stdout
where they can be piped to other applications or redirected to
files.
The names used for generated files and links all begin with the
string ntpkey
and include the file type,
generating host and filestamp,
as described in the Cryptographic Data Files section below.
To test and gain experience with Autokey concepts, log in as root and
change to the keys directory, usually /usr/local/etc
.
When run for the
first time, or if all files with names beginning ntpkey
] have been
removed, use the ntp-keygen
command without arguments to generate a
default RSA host key and matching RSA-MD5 certificate with expiration
date one year hence.
If run again without options, the program uses the
existing keys and parameters and generates only a new certificate with
new expiration date one year hence.
Run the command on as many hosts as necessary.
Designate one of them as the trusted host (TH) using ntp-keygen
with the -T
option and configure
it to synchronize from reliable Internet servers.
Then configure the other hosts to synchronize to the TH directly or indirectly.
A certificate trail is created when Autokey asks the immediately
ascendant host towards the TH to sign its certificate, which is then
provided to the immediately descendant host on request.
All group hosts should have acyclic certificate trails ending on the TH.
The host key is used to encrypt the cookie when required and so must be
RSA type.
By default, the host key is also the sign key used to encrypt signatures.
A different sign key can be assigned using the -S
option
and this can be either RSA or DSA type.
By default, the signature
message digest type is MD5, but any combination of sign key type and
message digest type supported by the OpenSSL library can be specified
using the -c
option.
The rules say cryptographic media should be generated with proventic filestamps, which means the host should already be synchronized before this program is run. This of course creates a chicken-and-egg problem when the host is started for the first time. Accordingly, the host time should be set by some other means, such as eyeball-and-wristwatch, at least so that the certificate lifetime is within the current year. After that and when the host is synchronized to a proventic source, the certificate should be re-generated.
Additional information on trusted groups and identity schemes is on the Autokey Public-Key Authentication page.
This program generates cryptographic data files used by the NTPv4 authentication and identification schemes. It generates MD5 key files used in symmetric key cryptography. In addition, if the OpenSSL software library has been installed, it generates keys, certificate and identity files used in public key cryptography. These files are used for cookie encryption, digital signature and challenge/response identification algorithms compatible with the Internet standard security infrastructure.
All files are in PEM-encoded printable ASCII format, so they can be embedded as MIME attachments in mail to other sites and certificate authorities. By default, files are not encrypted.
When used to generate message digest keys, the program produces a file
containing ten pseudo-random printable ASCII strings suitable for the
MD5 message digest algorithm included in the distribution.
If the OpenSSL library is installed, it produces an additional ten
hex-encoded random bit strings suitable for the SHA1 and other message
digest algorithms.
The message digest keys file must be distributed and stored
using secure means beyond the scope of NTP itself.
Besides the keys used for ordinary NTP associations, additional keys
can be defined as passwords for the
ntpq(1ntpqmdoc)
and
ntpdc(1ntpdcmdoc)
utility programs.
The remaining generated files are compatible with other OpenSSL applications and other Public Key Infrastructure (PKI) resources. Certificates generated by this program are compatible with extant industry practice, although some users might find the interpretation of X509v3 extension fields somewhat liberal. However, the identity keys are probably not compatible with anything other than Autokey.
Some files used by this program are encrypted using a private password.
The
-p
option specifies the password for local encrypted files and the
-q
option the password for encrypted files sent to remote sites.
If no password is specified, the host name returned by the Unix
gethostname
()
function, normally the DNS name of the host is used.
The pw option of the crypto configuration command specifies the read password for previously encrypted local files. This must match the local password used by this program. If not specified, the host name is used. Thus, if files are generated by this program without password, they can be read back by ntpd without password but only on the same host.
Normally, encrypted files for each host are generated by that host and used only by that host, although exceptions exist as noted later on this page. The symmetric keys file, normally called ntp.keys, is usually installed in /etc. Other files and links are usually installed in /usr/local/etc, which is normally in a shared filesystem in NFS-mounted networks and cannot be changed by shared clients. The location of the keys directory can be changed by the keysdir configuration command in such cases. Normally, this is in /etc.
This program directs commentary and error messages to the standard error stream stderr and remote files to the standard output stream stdout where they can be piped to other applications or redirected to files. The names used for generated files and links all begin with the string ntpkey and include the file type, generating host and filestamp, as described in the Cryptographic Data Files section below.
To test and gain experience with Autokey concepts, log in as root and
change to the keys directory, usually
/usr/local/etc
When run for the first time, or if all files with names beginning with
ntpkey
have been removed, use the
ntp-keygen
command without arguments to generate a
default RSA host key and matching RSA-MD5 certificate with expiration
date one year hence.
If run again without options, the program uses the
existing keys and parameters and generates only a new certificate with
new expiration date one year hence.
Run the command on as many hosts as necessary.
Designate one of them as the trusted host (TH) using
ntp-keygen
with the
-T
option and configure it to synchronize from reliable Internet servers.
Then configure the other hosts to synchronize to the TH directly or
indirectly.
A certificate trail is created when Autokey asks the immediately
ascendant host towards the TH to sign its certificate, which is then
provided to the immediately descendant host on request.
All group hosts should have acyclic certificate trails ending on the TH.
The host key is used to encrypt the cookie when required and so must be
RSA type.
By default, the host key is also the sign key used to encrypt
signatures.
A different sign key can be assigned using the
-S
option and this can be either RSA or DSA type.
By default, the signature
message digest type is MD5, but any combination of sign key type and
message digest type supported by the OpenSSL library can be specified
using the
-c
option.
The rules say cryptographic media should be generated with proventic
filestamps, which means the host should already be synchronized before
this program is run.
This of course creates a chicken-and-egg problem
when the host is started for the first time.
Accordingly, the host time
should be set by some other means, such as eyeball-and-wristwatch, at
least so that the certificate lifetime is within the current year.
After that and when the host is synchronized to a proventic source, the
certificate should be re-generated.
Additional information on trusted groups and identity schemes is on the Autokey Public-Key Authentication page.
The
ntpd(1ntpdmdoc)
configuration command
crypto
pw
password
specifies the read password for previously encrypted files.
The daemon expires on the spot if the password is missing
or incorrect.
For convenience, if a file has been previously encrypted,
the default read password is the name of the host running
the program.
If the previous write password is specified as the host name,
these files can be read by that host with no explicit password.
File names begin with the prefix
ntpkey_
and end with the postfix
_hostname.filestamp,
where
hostname
is the owner name, usually the string returned
by the Unix gethostname() routine, and
filestamp
is the NTP seconds when the file was generated, in decimal digits.
This both guarantees uniqueness and simplifies maintenance
procedures, since all files can be quickly removed
by a
rm
ntpkey*
command or all files generated
at a specific time can be removed by a
rm
*filestamp
command.
To further reduce the risk of misconfiguration,
the first two lines of a file contain the file name
and generation date and time as comments.
All files are installed by default in the keys directory /usr/local/etc, which is normally in a shared filesystem in NFS-mounted networks. The actual location of the keys directory and each file can be overridden by configuration commands, but this is not recommended. Normally, the files for each host are generated by that host and used only by that host, although exceptions exist as noted later on this page.
Normally, files containing private values, including the host key, sign key and identification parameters, are permitted root read/write-only; while others containing public values are permitted world readable. Alternatively, files containing private values can be encrypted and these files permitted world readable, which simplifies maintenance in shared file systems. Since uniqueness is insured by the hostname and file name extensions, the files for a NFS server and dependent clients can all be installed in the same shared directory.
The recommended practice is to keep the file name extensions
when installing a file and to install a soft link
from the generic names specified elsewhere on this page
to the generated files.
This allows new file generations to be activated simply
by changing the link.
If a link is present, ntpd follows it to the file name
to extract the filestamp.
If a link is not present,
ntpd(1ntpdmdoc)
extracts the filestamp from the file itself.
This allows clients to verify that the file and generation times
are always current.
The
ntp-keygen
program uses the same timestamp extension for all files generated
at one time, so each generation is distinct and can be readily
recognized in monitoring data.
The safest way to run the
ntp-keygen
program is logged in directly as root.
The recommended procedure is change to the keys directory,
usually
/usr/local/etc,
then run the program.
When run for the first time,
or if all
ntpkey
files have been removed,
the program generates a RSA host key file and matching RSA-MD5 certificate file,
which is all that is necessary in many cases.
The program also generates soft links from the generic names
to the respective files.
If run again, the program uses the same host key file,
but generates a new certificate file and link.
The host key is used to encrypt the cookie when required and so must be RSA type. By default, the host key is also the sign key used to encrypt signatures. When necessary, a different sign key can be specified and this can be either RSA or DSA type. By default, the message digest type is MD5, but any combination of sign key type and message digest type supported by the OpenSSL library can be specified, including those using the MD2, MD5, SHA, SHA1, MDC2 and RIPE160 message digest algorithms. However, the scheme specified in the certificate must be compatible with the sign key. Certificates using any digest algorithm are compatible with RSA sign keys; however, only SHA and SHA1 certificates are compatible with DSA sign keys.
Private/public key files and certificates are compatible with other OpenSSL applications and very likely other libraries as well. Certificates or certificate requests derived from them should be compatible with extant industry practice, although some users might find the interpretation of X509v3 extension fields somewhat liberal. However, the identification parameter files, although encoded as the other files, are probably not compatible with anything other than Autokey.
Running the program as other than root and using the Unix
su
command
to assume root may not work properly, since by default the OpenSSL library
looks for the random seed file
.rnd
in the user home directory.
However, there should be only one
.rnd
,
most conveniently
in the root directory, so it is convenient to define the
$RANDFILE
environment variable used by the OpenSSL library as the path to
/.rnd
.
Installing the keys as root might not work in NFS-mounted
shared file systems, as NFS clients may not be able to write
to the shared keys directory, even as root.
In this case, NFS clients can specify the files in another
directory such as
/etc
using the
keysdir
command.
There is no need for one client to read the keys and certificates
of other clients or servers, as these data are obtained automatically
by the Autokey protocol.
Ordinarily, cryptographic files are generated by the host that uses them, but it is possible for a trusted agent (TA) to generate these files for other hosts; however, in such cases files should always be encrypted. The subject name and trusted name default to the hostname of the host generating the files, but can be changed by command line options. It is convenient to designate the owner name and trusted name as the subject and issuer fields, respectively, of the certificate. The owner name is also used for the host and sign key files, while the trusted name is used for the identity files.
All files are installed by default in the keys directory /usr/local/etc, which is normally in a shared filesystem in NFS-mounted networks. The actual location of the keys directory and each file can be overridden by configuration commands, but this is not recommended. Normally, the files for each host are generated by that host and used only by that host, although exceptions exist as noted later on this page.
Normally, files containing private values, including the host key, sign key and identification parameters, are permitted root read/write-only; while others containing public values are permitted world readable. Alternatively, files containing private values can be encrypted and these files permitted world readable, which simplifies maintenance in shared file systems. Since uniqueness is insured by the hostname and file name extensions, the files for a NFS server and dependent clients can all be installed in the same shared directory.
The recommended practice is to keep the file name extensions
when installing a file and to install a soft link
from the generic names specified elsewhere on this page
to the generated files.
This allows new file generations to be activated simply
by changing the link.
If a link is present, ntpd follows it to the file name
to extract the filestamp.
If a link is not present,
ntpd(1ntpdmdoc)
extracts the filestamp from the file itself.
This allows clients to verify that the file and generation times
are always current.
The
ntp-keygen
program uses the same timestamp extension for all files generated
at one time, so each generation is distinct and can be readily
recognized in monitoring data.
The safest way to run the
ntp-keygen
program is logged in directly as root.
The recommended procedure is change to the keys directory,
usually
/usr/local/etc,
then run the program.
When run for the first time,
or if all
ntpkey
files have been removed,
the program generates a RSA host key file and matching RSA-MD5 certificate file,
which is all that is necessary in many cases.
The program also generates soft links from the generic names
to the respective files.
If run again, the program uses the same host key file,
but generates a new certificate file and link.
The host key is used to encrypt the cookie when required and so must be RSA type. By default, the host key is also the sign key used to encrypt signatures. When necessary, a different sign key can be specified and this can be either RSA or DSA type. By default, the message digest type is MD5, but any combination of sign key type and message digest type supported by the OpenSSL library can be specified, including those using the MD2, MD5, SHA, SHA1, MDC2 and RIPE160 message digest algorithms. However, the scheme specified in the certificate must be compatible with the sign key. Certificates using any digest algorithm are compatible with RSA sign keys; however, only SHA and SHA1 certificates are compatible with DSA sign keys.
Private/public key files and certificates are compatible with other OpenSSL applications and very likely other libraries as well. Certificates or certificate requests derived from them should be compatible with extant industry practice, although some users might find the interpretation of X509v3 extension fields somewhat liberal. However, the identification parameter files, although encoded as the other files, are probably not compatible with anything other than Autokey.
Running the program as other than root and using the Unix
su
command
to assume root may not work properly, since by default the OpenSSL library
looks for the random seed file
.rnd
in the user home directory.
However, there should be only one
.rnd
,
most conveniently
in the root directory, so it is convenient to define the
$RANDFILE
environment variable used by the OpenSSL library as the path to
/.rnd
.
Installing the keys as root might not work in NFS-mounted
shared file systems, as NFS clients may not be able to write
to the shared keys directory, even as root.
In this case, NFS clients can specify the files in another
directory such as
/etc
using the
keysdir
command.
There is no need for one client to read the keys and certificates
of other clients or servers, as these data are obtained automatically
by the Autokey protocol.
Ordinarily, cryptographic files are generated by the host that uses them, but it is possible for a trusted agent (TA) to generate these files for other hosts; however, in such cases files should always be encrypted. The subject name and trusted name default to the hostname of the host generating the files, but can be changed by command line options. It is convenient to designate the owner name and trusted name as the subject and issuer fields, respectively, of the certificate. The owner name is also used for the host and sign key files, while the trusted name is used for the identity files. seconds. seconds.
s Trusted Hosts and Groups
Each cryptographic configuration involves selection of a signature scheme
and identification scheme, called a cryptotype,
as explained in the
Authentication Options
section of
ntp.conf(5)
.
The default cryptotype uses RSA encryption, MD5 message digest
and TC identification.
First, configure a NTP subnet including one or more low-stratum
trusted hosts from which all other hosts derive synchronization
directly or indirectly.
Trusted hosts have trusted certificates;
all other hosts have nontrusted certificates.
These hosts will automatically and dynamically build authoritative
certificate trails to one or more trusted hosts.
A trusted group is the set of all hosts that have, directly or indirectly,
a certificate trail ending at a trusted host.
The trail is defined by static configuration file entries
or dynamic means described on the
Automatic NTP Configuration Options
section of
ntp.conf(5)
.
On each trusted host as root, change to the keys directory.
To insure a fresh fileset, remove all
ntpkey
files.
Then run
ntp-keygen
-T
to generate keys and a trusted certificate.
On all other hosts do the same, but leave off the
-T
flag to generate keys and nontrusted certificates.
When complete, start the NTP daemons beginning at the lowest stratum
and working up the tree.
It may take some time for Autokey to instantiate the certificate trails
throughout the subnet, but setting up the environment is completely automatic.
If it is necessary to use a different sign key or different digest/signature
scheme than the default, run
ntp-keygen
with the
-S
-type
option, where
type
is either
RSA
or
DSA
.
The most often need to do this is when a DSA-signed certificate is used.
If it is necessary to use a different certificate scheme than the default,
run
ntp-keygen
with the
-c
-scheme
option and selected
scheme
as needed.
f
ntp-keygen
is run again without these options, it generates a new certificate
using the same scheme and sign key.
After setting up the environment it is advisable to update certificates
from time to time, if only to extend the validity interval.
Simply run
ntp-keygen
with the same flags as before to generate new certificates
using existing keys.
However, if the host or sign key is changed,
ntpd(1ntpdmdoc)
should be restarted.
When
ntpd(1ntpdmdoc)
is restarted, it loads any new files and restarts the protocol.
Other dependent hosts will continue as usual until signatures are refreshed,
at which time the protocol is restarted.
As mentioned on the Autonomous Authentication page,
the default TC identity scheme is vulnerable to a middleman attack.
However, there are more secure identity schemes available,
including PC, IFF, GQ and MV described on the
"Identification Schemes"
page
(maybe available at
http://www.eecis.udel.edu/%7emills/keygen.html
).
These schemes are based on a TA, one or more trusted hosts
and some number of nontrusted hosts.
Trusted hosts prove identity using values provided by the TA,
while the remaining hosts prove identity using values provided
by a trusted host and certificate trails that end on that host.
The name of a trusted host is also the name of its sugroup
and also the subject and issuer name on its trusted certificate.
The TA is not necessarily a trusted host in this sense, but often is.
In some schemes there are separate keys for servers and clients. A server can also be a client of another server, but a client can never be a server for another client. In general, trusted hosts and nontrusted hosts that operate as both server and client have parameter files that contain both server and client keys. Hosts that operate only as clients have key files that contain only client keys.
The PC scheme supports only one trusted host in the group.
On trusted host alice run
ntp-keygen
-P
-p
-password
to generate the host key file
ntpkey_RSAkey_alice.filestamp
and trusted private certificate file
ntpkey_RSA-MD5_cert_alice.filestamp.
Copy both files to all group hosts;
they replace the files which would be generated in other schemes.
On each host bob install a soft link from the generic name
ntpkey_host_bob
to the host key file and soft link
ntpkey_cert_bob
to the private certificate file.
Note the generic links are on bob, but point to files generated
by trusted host alice.
In this scheme it is not possible to refresh
either the keys or certificates without copying them
to all other hosts in the group.
For the IFF scheme proceed as in the TC scheme to generate keys
and certificates for all group hosts, then for every trusted host in the group,
generate the IFF parameter file.
On trusted host alice run
ntp-keygen
-T
-I
-p
-password
to produce her parameter file
ntpkey_IFFpar_alice.filestamp,
which includes both server and client keys.
Copy this file to all group hosts that operate as both servers
and clients and install a soft link from the generic
ntpkey_iff_alice
to this file.
If there are no hosts restricted to operate only as clients,
there is nothing further to do.
As the IFF scheme is independent
of keys and certificates, these files can be refreshed as needed.
If a rogue client has the parameter file, it could masquerade
as a legitimate server and present a middleman threat.
To eliminate this threat, the client keys can be extracted
from the parameter file and distributed to all restricted clients.
After generating the parameter file, on alice run
ntp-keygen
-e
and pipe the output to a file or mail program.
Copy or mail this file to all restricted clients.
On these clients install a soft link from the generic
ntpkey_iff_alice
to this file.
To further protect the integrity of the keys,
each file can be encrypted with a secret password.
For the GQ scheme proceed as in the TC scheme to generate keys
and certificates for all group hosts, then for every trusted host
in the group, generate the IFF parameter file.
On trusted host alice run
ntp-keygen
-T
-G
-p
-password
to produce her parameter file
ntpkey_GQpar_alice.filestamp,
which includes both server and client keys.
Copy this file to all group hosts and install a soft link
from the generic
ntpkey_gq_alice
to this file.
In addition, on each host bob install a soft link
from generic
ntpkey_gq_bob
to this file.
As the GQ scheme updates the GQ parameters file and certificate
at the same time, keys and certificates can be regenerated as needed.
For the MV scheme, proceed as in the TC scheme to generate keys
and certificates for all group hosts.
For illustration assume trish is the TA, alice one of several trusted hosts
and bob one of her clients.
On TA trish run
ntp-keygen
-V
-n
-p
-password,
where
n
is the number of revokable keys (typically 5) to produce
the parameter file
ntpkeys_MVpar_trish.filestamp
and client key files
ntpkeys_MVkeyd_trish.filestamp
where
d
is the key number (0 \&<
d
\&<
n).
Copy the parameter file to alice and install a soft link
from the generic
ntpkey_mv_alice
to this file.
Copy one of the client key files to alice for later distribution
to her clients.
It doesn't matter which client key file goes to alice,
since they all work the same way.
Alice copies the client key file to all of her cliens.
On client bob install a soft link from generic
ntpkey_mvkey_bob
to the client key file.
As the MV scheme is independent of keys and certificates,
these files can be refreshed as needed.
-c
-schemeor
DSA-SHA1
.
Note that RSA schemes must be used with a RSA sign key and DSA
schemes must be used with a DSA sign key.
The default without this option is
RSA-MD5
.
-d
-e
-G
-g
-H
-I
-i
-name-M
-P
-p
-password-q
-S
-Oo
-Cm
-RSA
-
| -DSA
-Oc
-s
-name-T
-V
-nkeysAll cryptographically sound key generation schemes must have means
to randomize the entropy seed used to initialize
the internal pseudo-random number generator used
by the library routines.
The OpenSSL library uses a designated random seed file for this purpose.
The file must be available when starting the NTP daemon and
ntp-keygen
program.
If a site supports OpenSSL or its companion OpenSSH,
it is very likely that means to do this are already available.
It is important to understand that entropy must be evolved for each generation, for otherwise the random number sequence would be predictable. Various means dependent on external events, such as keystroke intervals, can be used to do this and some systems have built-in entropy sources. Suitable means are described in the OpenSSL software documentation, but are outside the scope of this page.
The entropy seed used by the OpenSSL library is contained in a file,
usually called
.rnd
,
which must be available when starting the NTP daemon
or the
ntp-keygen
program.
The NTP daemon will first look for the file
using the path specified by the
randfile
subcommand of the
crypto
configuration command.
If not specified in this way, or when starting the
ntp-keygen
program,
the OpenSSL library will look for the file using the path specified
by the
Ev RANDFILE
environment variable in the user home directory,
whether root or some other user.
If the
Ev RANDFILE
environment variable is not present,
the library will look for the
.rnd
file in the user home directory.
If the file is not available or cannot be written,
the daemon exits with a message to the system log and the program
exits with a suitable error message.
All other file formats begin with two lines.
The first contains the file name, including the generated host name
and filestamp.
The second contains the datestamp in conventional Unix date format.
Lines beginning with # are considered comments and ignored by the
ntp-keygen
program and
ntpd(1ntpdmdoc)
daemon.
Cryptographic values are encoded first using ASN.1 rules,
then encrypted if necessary, and finally written PEM-encoded
printable ASCII format preceded and followed by MIME content identifier lines.
The format of the symmetric keys file is somewhat different than the other files in the interest of backward compatibility. Since DES-CBC is deprecated in NTPv4, the only key format of interest is MD5 alphanumeric strings. Following hte heard the keys are entered one per line in the format
keyno type key
where keyno is a positive integer in the range 1-65,535, type is the string MD5 defining the key format and key is the key itself, which is a printable ASCII string 16 characters or less in length. Each character is chosen from the 93 printable characters in the range 0x21 through 0x7f excluding space and the # character.
Note that the keys used by the
ntpq(1ntpqmdoc)
and
ntpdc(1ntpdcmdoc)
programs
are checked against passwords requested by the programs
and entered by hand, so it is generally appropriate to specify these keys
in human readable ASCII format.
The
ntp-keygen
program generates a MD5 symmetric keys file
ntpkey_MD5key_hostname.filestamp.
Since the file contains private shared keys,
it should be visible only to root and distributed by secure means
to other subnet hosts.
The NTP daemon loads the file
ntp.keys,
so
ntp-keygen
installs a soft link from this name to the generated file.
Subsequently, similar soft links must be installed by manual
or automated means on the other subnet hosts.
While this file is not used with the Autokey Version 2 protocol,
it is needed to authenticate some remote configuration commands
used by the
ntpq(1ntpqmdoc)
and
ntpdc(1ntpdcmdoc)
utilities.
This section was generated by AutoGen,
using the agtexi-cmd
template and the option descriptions for the ntp-keygen
program.
This software is released under the NTP license, <http://ntp.org/license>.
This is the automatically generated usage text for ntp-keygen.
The text printed is the same whether selected with the help
option
(--help) or the more-help
option (--more-help). more-help
will print
the usage text by passing it through a pager program.
more-help
is disabled on platforms without a working
fork(2)
function. The PAGER
environment variable is
used to select the program, defaulting to more. Both will exit
with a status code of 0.
ntp-keygen (ntp) - Create a NTP host key - Ver. 4.2.7p367 Usage: ntp-keygen [ -<flag> [<val>] | --<name>[{=| }<val>] ]... Flg Arg Option-Name Description -b Num imbits identity modulus bits - it must be in the range: 256 to 2048 -c Str certificate certificate scheme -C Str cipher privatekey cipher -d no debug-level Increase debug verbosity level - may appear multiple times -D Num set-debug-level Set the debug verbosity level - may appear multiple times -e no id-key Write IFF or GQ identity keys -G no gq-params Generate GQ parameters and keys -H no host-key generate RSA host key -I no iffkey generate IFF parameters -i Str ident set Autokey group name -l Num lifetime set certificate lifetime -M no md5key generate MD5 keys -m Num modulus modulus - it must be in the range: 256 to 2048 -P no pvt-cert generate PC private certificate -p Str pvt-passwd output private password -q Str get-pvt-passwd input private password -S Str sign-key generate sign key (RSA or DSA) -s Str subject-name set host and optionally group name -T no trusted-cert trusted certificate (TC scheme) -V Num mv-params generate <num> MV parameters -v Num mv-keys update <num> MV keys opt version output version information and exit -? no help display extended usage information and exit -! no more-help extended usage information passed thru pager -> opt save-opts save the option state to a config file -< Str load-opts load options from a config file - disabled as '--no-load-opts' - may appear multiple times Options are specified by doubled hyphens and their name or by a single hyphen and the flag character. The following option preset mechanisms are supported: - reading file $HOME/.ntprc - reading file ./.ntprc - examining environment variables named NTP_KEYGEN_* Please send bug reports to: <http://bugs.ntp.org<EMAIL_ADDRESS>This is the “identity modulus bits” option. This option takes an argument number imbits.
This option has some usage constraints. It:
AUTOKEY
during the compilation.
The number of bits in the identity modulus. The default is 256.
This is the “certificate scheme” option. This option takes an argument string scheme.
This option has some usage constraints. It:
AUTOKEY
during the compilation.
scheme is one of RSA-MD2, RSA-MD5, RSA-SHA, RSA-SHA1, RSA-MDC2, RSA-RIPEMD160, DSA-SHA, or DSA-SHA1.
Select the certificate message digest/signature encryption scheme. Note that RSA schemes must be used with a RSA sign key and DSA schemes must be used with a DSA sign key. The default without this option is RSA-MD5.
This is the “privatekey cipher” option. This option takes an argument string cipher.
This option has some usage constraints. It:
AUTOKEY
during the compilation.
Select the cipher which is used to encrypt the files containing
private keys. The default is three-key triple DES in CBC mode,
equivalent to "-C des-ede3-cbc". The openssl tool lists ciphers
available in "openssl -h" output.
This is the “write iff or gq identity keys” option.
This option has some usage constraints. It:
AUTOKEY
during the compilation.
Write the IFF or GQ client keys to the standard output. This is intended for automatic key distribution by mail.
This is the “generate gq parameters and keys” option.
This option has some usage constraints. It:
AUTOKEY
during the compilation.
Generate parameters and keys for the GQ identification scheme, obsoleting any that may exist.
This is the “generate rsa host key” option.
This option has some usage constraints. It:
AUTOKEY
during the compilation.
Generate new host keys, obsoleting any that may exist.
This is the “generate iff parameters” option.
This option has some usage constraints. It:
AUTOKEY
during the compilation.
Generate parameters for the IFF identification scheme, obsoleting any that may exist.
This is the “set autokey group name” option. This option takes an argument string group.
This option has some usage constraints. It:
AUTOKEY
during the compilation.
Set the optional Autokey group name to name. This is used in
the file name of IFF, GQ, and MV client parameters files. In
that role, the default is the host name if this option is not
provided. The group name, if specified using 'crypto ident' or 'server ident' configuration in
ntpd's configuration file.
-i/--ident
or
using -s/--subject-name
following an '}' character,
is also a part of the self-signed host certificate's subject and
issuer names in the form host
This is the ``set certificate lifetime'' option. This option takes an argument number lifetime.
This option has some usage constraints. It:
AUTOKEY
during the compilation.
Set the certificate expiration to lifetime days from now.
This is the ``generate md5 keys'' option. Generate MD5 keys, obsoleting any that may exist.
This is the ``modulus'' option. This option takes an argument number modulus.
This option has some usage constraints. It:
AUTOKEY
during the compilation.
The number of bits in the prime modulus. The default is 512.
This is the ``generate pc private certificate'' option.
This option has some usage constraints. It:
AUTOKEY
during the compilation.
Generate a private certificate. By default, the program generates public certificates.
This is the ``output private password'' option. This option takes an argument string passwd.
This option has some usage constraints. It:
AUTOKEY
during the compilation.
Encrypt generated files containing private data with the specified
password and the cipher selected with -C/--cipher
.
This is the ``input private password'' option. This option takes an argument string passwd.
This option has some usage constraints. It:
AUTOKEY
during the compilation.
Set the password for reading files to the specified password.
This is the ``generate sign key (rsa or dsa)'' option. This option takes an argument string sign.
This option has some usage constraints. It:
AUTOKEY
during the compilation.
Generate a new sign key of the designated type, obsoleting any that may exist. By default, the program uses the host key as the sign key.
This is the ``set host and optionally group name'' option. This option takes an argument string host@group.
This option has some usage constraints. It:
AUTOKEY
during the compilation.
Set the Autokey host name, and optionally, group name specified
following an ' fields. Specifying '-s
leaving the host name unchanged while appending
subject and issuer fields, as with -i group. The group name, or
if not provided, the host name are also used in the file names
of IFF, GQ, and MV client parameter files.
}' character. The host name is used in the file
name of generated host and signing certificates, without the
group name. The host name, and if provided, group name are used
in host
This is the ``trusted certificate (tc scheme)'' option.
This option has some usage constraints. It:
AUTOKEY
during the compilation.
Generate a trusted certificate. By default, the program generates a non-trusted certificate.
This is the ``generate <num> mv parameters'' option. This option takes an argument number num.
This option has some usage constraints. It:
AUTOKEY
during the compilation.
Generate parameters and keys for the Mu-Varadharajan (MV) identification scheme.
This is the ``update <num> mv keys'' option. This option takes an argument number num.
This option has some usage constraints. It:
AUTOKEY
during the compilation.
This option has no doc documentation.
Any option that is not marked as not presettable may be preset by
loading values from configuration ("rc" or "ini") files, and values from environment variables named NTP-KEYGEN
and NTP-KEYGEN_<OPTION_NAME>
. <OPTION_NAME>
must be one of
the options listed above in upper case and segmented with underscores.
The NTP-KEYGEN
variable will be tokenized and parsed like
the command line. The remaining variables are tested for existence and their
values are treated like option arguments.
libopts
will search in 2 places for configuration files:
HOME
, and PWD
are expanded and replaced when ntp-keygen runs.
For any of these that are plain files, they are simply processed.
For any that are directories, then a file named .ntprc is searched for
within that directory and processed.
Configuration files may be in a wide variety of formats. The basic format is an option name followed by a value (argument) on the same line. Values may be separated from the option name with a colon, equal sign or simply white space. Values may be continued across multiple lines by escaping the newline with a backslash.
Multiple programs may also share the same initialization file. Common options are collected at the top, followed by program specific segments. The segments are separated by lines like:
[NTP-KEYGEN]
or by
<?program ntp-keygen>
Do not mix these styles within one configuration file.
Compound values and carefully constructed string values may also be specified using XML syntax:
<option-name> <sub-opt>...<...>...</sub-opt> </option-name>
yielding an option-name.sub-opt
string value of
"...<...>..."
AutoOpts
does not track suboptions. You simply note that it is a
hierarchicly valued option. AutoOpts
does provide a means for searching
the associated name/value pair list (see: optionFindValue).
The command line options relating to configuration and/or usage help are:
Print the program version to standard out, optionally with licensing information, then exit 0. The optional argument specifies how much licensing detail to provide. The default is to print just the version. The licensing infomation may be selected with an option argument. Only the first letter of the argument is examined:
One of the following exit values will be returned:
All cryptographically sound key generation schemes must have means to
randomize the entropy seed used to initialize the internal
pseudo-random number generator used by the OpenSSL library routines.
If a site supports ssh, it is very likely that means to do this are
already available.
The entropy seed used by the OpenSSL library is contained in a file,
usually called .rnd
, which must be available when
starting the ntp-keygen
program or ntpd
daemon.
The OpenSSL library looks for the file using the path specified by the
RANDFILE
environment variable in the user home directory, whether root
or some other user.
If the RANDFILE
environment variable is not
present, the library looks for the .rnd
file in the user home
directory.
Since both the ntp-keygen
program and ntpd
daemon must run
as root, the logical place to put this file is in /.rnd
or
/root/.rnd
.
If the file is not available or cannot be written, the program exits
with a message to the system log.
File and link names are in the form ntpkey_key_name.fstamp
,
where key
is the key or parameter type,
name
is the host or group name and
fstamp
is the filestamp (NTP seconds) when the file was created).
By convention, key names in generated file names include both upper and
lower case characters, while key names in generated link names include
only lower case characters. The filestamp is not used in generated link
names.
The key name is a string defining the cryptographic key type. Key types include public/private keys host and sign, certificate cert and several challenge/response key types. By convention, client files used for challenges have a par subtype, as in the IFF challenge IFFpar, while server files for responses have a key subtype, as in the GQ response GQkey.
All files begin with two nonencrypted lines. The first line contains
the file name in the format ntpkey_key_host.fstamp
.
The second line contains the datestamp in conventional Unix date format.
Lines beginning with #
are ignored.
The remainder of the file contains cryptographic data encoded first using ASN.1 rules, then encrypted using the DES-CBC algorithm with given password and finally written in PEM-encoded printable ASCII text preceded and followed by MIME content identifier lines.
The format of the symmetric keys file, ordinarily named ntp.keys
,
is somewhat different than the other files in the interest of backward
compatibility.
Ordinarily, the file is generated by this program, but
it can be constructed and edited using an ordinary text editor.
# ntpkey_MD5key_hms.local.3564038757 # Sun Dec 9 02:45:57 2012 1 MD5 "]!ghT%O;3)WJ,/Nc:>I # MD5 key 2 MD5 lu+H^tF46BKR-6~pV_5 # MD5 key 3 MD5 :lnoVsE%Yz*avh%EtNC # MD5 key 4 MD5 |fdZrf0sF~^V # MD5 key 5 MD5 IyAG>O"y"LmCRS!*bHC # MD5 key 6 MD5 ">e\A # MD5 key 7 MD5 c9x=M'CfLxax9v)PV-si # MD5 key 8 MD5 E|=jvFVov?Bn|Ev=&aK\ # MD5 key 9 MD5 T!c4UT&`(m$+m+B6,`Q0 # MD5 key 10 MD5 JVF/1=)=IFbHbJQz..Cd # MD5 key 11 SHA1 6dea311109529e436c2b4fccae9bc753c16d1b48 # SHA1 key 12 SHA1 7076f373d86c4848c59ff8046e49cb7d614ec394 # SHA1 key 13 SHA1 5f48b1b60591eb01b7cf1d33b7774f08d20262d3 # SHA1 key 14 SHA1 eed5ab9d9497319ec60cf3781d52607e76720178 # SHA1 key 15 SHA1 f283562611a04c964da8126296f5f8e58c3f85de # SHA1 key 16 SHA1 1930da171297dd63549af50b29449de17dcf341f # SHA1 key 17 SHA1 fee892110358cd4382322b889869e750db8e8a8f # SHA1 key 18 SHA1 b5520c9fadd7ad3fd8bfa061c8821b65d029bb37 # SHA1 key 19 SHA1 8c74fb440ec80f453ec6aaa62b9baed0ab723b92 # SHA1 key 20 SHA1 6bc05f734306a189326000970c19b3910f403795 # SHA1 key
Figure 1. Typical Symmetric Key File
Figure 1 shows a typical symmetric keys file used by the reference implementation. Each line of the file contains three fields, first an integer between 1 and 65534, inclusive, representing the key identifier used in the server and peer configuration commands. Next is the key type for the message digest algorithm, which in the absence of the OpenSSL library must be MD5 to designate the MD5 message digest algorithm. If the OpenSSL library is installed, the key type can be any message digest algorithm supported by that library. However, if compatibility with FIPS 140-2 is required, the key type must be either SHA or SHA1. The key type can be changed using an ASCII text editor.
An MD5 key consists of a printable ASCII string less than or equal to 16 characters and terminated by whitespace or a # character. An OpenSSL key consists of a hex-encoded ASCII string of 40 characters, which is truncated as necessary.
Note that the keys used by the ntpq
and ntpdc
programs are
checked against passwords requested by the programs and entered by hand,
so it
is generally appropriate to specify these keys in human readable ASCII
format.
The ntp-keygen
program generates a MD5 symmetric keys file
ntpkey_MD5key_hostname.filestamp
.
Since the file contains private
shared keys, it should be visible only to root and distributed by
secure means to other subnet hosts.
The NTP daemon loads the file ntp.keys
, so ntp-keygen
installs a soft link from this name to the generated file.
Subsequently, similar soft links must be installed by
manual or automated means on the other subnet hosts.
While this file is
not used with the Autokey Version 2 protocol, it is needed to
authenticate some remote configuration commands used by the ntpq
and
ntpdc
utilities.


Tab Group
Tabs, per https://www.w3.org/TR/wai-aria-practices-1.1/#tabpanel .
Demo
The kangaroo is a marsupial from the family Macropodidae (macropods, meaning "large foot"). In common use the term is used to describe the largest species from this family, especially those of the genus Macropus: the red kangaroo, antilopine kangaroo, eastern grey kangaroo, and western grey kangaroo. Kangaroos are indigenous to Australia. The Australian government estimates that 34.3 million kangaroos lived within the commercial harvest areas of Australia in 2011, up from 25.1 million one year earlier.
The platypus (Ornithorhynchus anatinus), sometimes referred to as the duck-billed platypus, is a semiaquatic egg-laying mammal endemic to eastern Australia, including Tasmania. The platypus is the sole living representative of its family (Ornithorhynchidae) and genus (Ornithorhynchus), though a number of related species appear in the fossil record. Together with the four species of echidna, it is one of the five extant species of monotremes, the only mammals that lay eggs instead of giving birth to live young. Like other monotremes it senses prey through electrolocation. It is one of the few species of venomous mammals, as the male platypus has a spur on the hind foot that delivers a venom capable of causing severe pain to humans.
Kookaburras are terrestrial tree kingfishers of the genus Dacelo native to Australia and New Guinea, which grow to between 28–42 cm (11–17 in) in length. The name is a loanword from Wiradjuri guuguubarra, onomatopoeic of its call.
They are found in habitats ranging from humid forest to arid savanna, as well as in suburban areas with tall trees or near running water. Even though they belong to the larger group known as "kingfishers", kookaburras are not closely associated with water.
Echidnas, sometimes known as spiny anteaters, belong to the family Tachyglossidae in the monotreme order of egg-laying mammals. The four extant species of Echidnas and the platypus are the only living mammals that lay eggs and the only surviving members of the order Monotremata. The diet of some species consists of ants and termites, but they are not closely related to the true anteaters of the Americas, which are xenarthrans, along with sloths and armadillos. Echidnas live in Australia and New Guinea.
Goanna refers to some species of the genus Varanus found in Australia and Southeast Asia. Around 80 species of Varanus are known, 25 of which are found in Australia. This varied group of carnivorous reptiles ranges greatly in size and fills several ecological niches. Being predatory lizards, goannas are often quite large, or at least bulky, with sharp teeth and claws. The largest is the perentie (V. giganteus), which can grow over 2.5 m (8.2 ft) in length. The goanna features prominently in Aboriginal mythology and Australian folklore.
Properties
| Name | Default | Description | Change |
|---|---|---|---|
| index | 0 | the index of the active item | |
| boxed | false | true to draw the tabs with a squarish border around them |
Events
| Name | Args |
|---|---|
| changed | index: the index of the active item |
| activeChange (TabItem) | active: whether the changed item is active |
Code
import { TabGroup, TabItem } from "svelte-toolkit"; <TabGroup boxed={false} index={0}> {#each items as item} <TabItem id={item.id} header={item.header}>{item.text}</TabItem> {/each} </TabGroup> ~ OR ~ <TabGroup boxed={false} index={0}> {#each items as item} <TabItem id={item.id}>
{item.header}

{item.text}
 </TabItem> {/each} </TabGroup>


The freshman application fee is $60. You can pay it with a credit card on the ApplyTexas application. If you do not pay the application fee through ApplyTexas, you must pay by money order through the mail.
Fee Waivers
UTA does not offer application fee waivers for international students.
SUBMIT YOUR TRANSCRIPTS AND TEST SCORES
Submit documents to the Office of Admissions by mail or in person.
Submit your completed official secondary school (high school) transcripts, diplomas, certificates, and/or national test examination scores as appropriate for the educational system in your country by mail. You must possess the equivalent of a U.S. high school graduation.
Submit your official SAT scores directly from the testing agency. These scores must be received before an admission decision can be made.
Submit official college transcript/marksheets for all university coursework you may have taken.
Submit official TOEFL test scores if you are from a non-native English speaking country. The minimum acceptable TOEFL score is 550 for the paper based test, 213 for the computer based test, or 79 on the internet based test.
Transcripts/marksheets not issued in English must be accompanied by an exact word-for-word original English translation bearing the original university or translation agency attestation.
DEADLINES
Applications received after the posted deadlines could be subject to processing delays. Please note the scholarship deadlines may be earlier.
International Undergraduate General Application Deadlines


Forgotten Monument:
The fourth monument seems to be in the most dangerous part of the Swamp of Screams.


List of strings; optional
The licenses of the output files that this binary generates.
Describes the licenses of the output of the binary generated by
the rule. When a binary is referenced in a host attribute (for
example, the tools
attribute of
a genrule
), this license declaration is used rather
than the union of the licenses of its transitive closure. This
argument is useful when a binary is used as a tool during the
build of a rule, and it is not desirable for its license to leak
into the license of that rule. If this attribute is missing, the
license computation proceeds as if the host dependency was a
regular dependency.
(For more about the distinction between host and target configurations, see Build configurations in the Bazel manual.)
WARNING: in some cases (specifically, in genrules) the build tool cannot guarantee that the binary referenced by this attribute is actually used as a tool, and is not, for example, copied to the output. In these cases, it is the responsibility of the user to make sure that this is true.


15
1 David built houses for himself in the city of David. He prepared a place for the ark of God and set up a tent for it.
2 Then David said, "Only the Levites may carry the ark of God, for Yahweh has chosen them to carry it, and to serve him forever."
3 Then David assembled all Israel at Jerusalem, to bring up the ark of Yahweh to the place he had prepared for it.
4 David gathered together Aaron's descendants and the Levites.
5 From the descendants of Kohath, there was Uriel the leader and his relatives, 120 men.
6 From the descendants of Merari, there was Asaiah the leader and his relatives, 220 men.
7 From the descendants of Gershom, there was Joel the leader, and his relatives, 130 men.
8 From the descendants of Elizaphan, there was Shemaiah the leader, and his relatives, 200 men.
9 From the descendants of Hebron, there was Eliel the leader, and his relatives, 80 men.
10 From the descendants of Uzziel, there was Amminadab the leader, and his relatives, 112 men.
11 David called for Zadok and Abiathar the priests, and the Levites Uriel, Asaiah, Joel, Shemaiah, Eliel, and Amminadab.
12 He said to them, "You are the leaders of the Levite families. Dedicate yourselves to Yahweh, both you and your brothers, so that you may bring up the ark of Yahweh, the God of Israel, to the place that I have prepared for it.
13 You did not carry it the first time. That is why Yahweh our God broke out against us, for we did not seek him or obey his decree."
14 So the priests and the Levites dedicated themselves to bring up the ark of Yahweh, the God of Israel.
15 So the Levites carried the ark of God on their shoulders with the poles, as Moses had commanded—following the rules given by the word of Yahweh.
16 David spoke to the leaders of the Levites to assign their brothers to be musicians with musical instruments, stringed instruments, harps and cymbals, playing loudly and joyfully lifting up their voices.
17 So the Levites appointed Heman son of Joel and one of his brothers, Asaph son of Berechiah. They also appointed kinsmen from Merari's descendants and Ethan son of Kushaiah.
18 With them were their kinsmen of second rank: Zechariah, 1Some Hebrew manuscripts add the name "Ben," perhaps the name of Zechariah's father was omitted.
19 The musicians Heman, Asaph, and Ethan, were appointed to play loud bronze cymbals.
20 Zechariah, Aziel, Shemiramoth, Jehiel, Unni, Eliab, Maaseiah, and Benaiah played the stringed instruments, set to Alamoth.
21 Mattithiah, Eliphelehu, Mikneiah, Obed Edom, Jeiel, and Azaziah, led the way with harps set to the Sheminith.
22 Kenaniah, leader of the Levites in the singing, directed the singing because he was skillful.
23 Berechiah and Elkanah were guards for the ark.
24 Shebaniah, Joshaphat, Nethanel, Amasai, Zechariah, Benaiah, and Eliezer, the priests, were to blow the trumpets before the ark of God. Obed Edom and Jehiah were guards for the ark.
25 So David, the elders of Israel, and the commanders over thousands, went to bring up the ark of the covenant of Yahweh out of Obed Edom's house with rejoicing.
26 While God helped the Levites who carried the ark of the covenant of Yahweh, they sacrificed seven bulls and seven rams.
27 David was clothed with a robe of fine linen, as were the Levites who carried the ark, the singers, and Kenaniah, the leader of the song with the singers. David was wearing a linen ephod.
28 So all Israel brought up the ark of the covenant of Yahweh with joyful shouting, and with the sound of horns, with cymbals, with stringed instruments and harps.
29 But as the ark of the covenant of Yahweh came to the city of David, Michal, daughter of Saul, looked out the window. She saw King David dancing and celebrating. Then she despised him in her heart.


--- layout: post status: publish published: true title: "何谓信任?" author: Leask author_login: leask author_email<EMAIL_ADDRESS>author_url: https://leaskh.com wordpress_id: 304 wordpress_url: http://leaskh.wordpress.com/2008/02/13/%e4%bd%95%e8%b0%93%e4%bf%a1%e4%bb%bb date: '2008-02-13 14:56:55 +0800' date_gmt: '2008-02-13 14:56:55 +0800' categories: tags: [] comments: [] ---


Online Communication In the 1970’s
Overview
Along cam 1971, and the Email.
The official Email system. The first email was shipped out buy a engineer named Ray Tomlinson. He established this way of communication by separating man and machine by using the ‘@’ symbol. Interesting. Imagine if he used any other keyboard symbol? Ray Tomlinson is seen below.
This online form of communication was the used on the ARPANET. The ARPANET was the beginning of the official internet.
Next in came the ‘Talkomatic’ in 1974.
It was developed in 1973 by Doug Brown using the PLATO System. The Talkomatic was similar to a chat room. Users were logged in and could see each other type text and commutate instantly, except it was text only. Sorry, no sideways smiley faces or Emoji's here ☹☹☹☹☹.
The Bulletin Board Systems a.k.a. BBS, circa 1987.
Using the BBS one was able to set up a modem connected computers. This allowed users to dial into and gain access to a terminal. The BBS allowed people to leave text messages and even upload and download files.
BBS's were in many cases just someone's home computer and they allowed access to it from them to communicate (obviously). Other cases of the BBS were vast network systems with tons of phone lines. Some were run commercially as well. The first BBS Software was developed by a guy named Ward Christensen.


By gaining the property of emergence through self-organization, the enhancement of SOMs(self organizing maps) is called Emergent SOM (ESOM). The result of the projection by ESOM is a grid of neurons which can be visualised as a three dimensional landscape in form of the Umatrix. Further details can be found in the referenced publications (see url). This package offers tools for calculating and visualising the ESOM as well as Umatrix, Pmatrix and UStarMatrix. All the functionality is also available through graphical user interfaces implemented in 'shiny'.
| Version: | 3.1 |
| Depends: | R (≥ 3.0) |
| Imports: | Rcpp, ggplot2, shiny, shinyjs, reshape2, fields, plyr, png, tools, grid, abind, deldir, geometry, pdist, AdaptGauss |
| LinkingTo: | Rcpp |
| Suggests: | rgl |
| Published: | 2017-12-18 |
| Author: | Florian Lerch[aut,cre], Michael Thrun[aut], Felix Pape[ctb], Raphael Paebst[ctb], Alfred Ultsch[aut] |
| Maintainer: | Florian Lerch <lerch at mathematik.uni-marburg.de> |
| License: | GPL-3 |
| URL: | http://wscg.zcu.cz/wscg2016/short/A43-full.pdf |
| NeedsCompilation: | yes |
| CRAN checks: | Umatrix results |
| Reference manual: | Umatrix.pdf |
| Package source: | Umatrix_3.1.tar.gz |
| Windows binaries: | r-devel: Umatrix_3.1.zip, r-release: Umatrix_3.1.zip, r-oldrel: Umatrix_3.1.zip |
| OS X binaries: | r-release: Umatrix_3.1.tgz, r-oldrel: Umatrix_3.1.tgz |
| Old sources: | Umatrix archive |
Please use the canonical form https://CRAN.R-project.org/package=Umatrix to link to this page.


class CMApi::Configuration
Attributes
Defines the access token (Bearer) used with OAuth2.
Defines API keys used with API Key authentications.
@return [Hash] key: parameter name, value: parameter value (API key)
@example parameter name is “api_key”, API key is “xxx” (e.g. “api_key=xxx” in query string)
config.api_key['api_key'] = 'xxx'
Defines API key prefixes used with API Key authentications.
@return [Hash] key: parameter name, value: API key prefix
@example parameter name is “Authorization”, API key prefix is “Token” (e.g. “Authorization: Token xxx” in headers)
config.api_key_prefix['api_key'] = 'Token'
Defines url base path
Client certificate file (for client certificate)
Set this to enable/disable debugging. When enabled (set to true), HTTP request/response details will be logged with `logger.debug` (see the `logger` attribute). Default to false.
@return [true, false]
Defines url host
Client private key file (for client certificate)
Defines the logger used for debugging. Default to `Rails.logger` (when in Rails) or logging to STDOUT.
@return [#debug]
Defines the password used with HTTP basic authentication.
@return [String]
Defines url scheme
Set this to customize the certificate file to verify the peer.
@return [String] the path to the certificate file
@see The `cainfo` option of Typhoeus, `–cert` option of libcurl. Related source code: github.com/typhoeus/typhoeus/blob/master/lib/typhoeus/easy_factory.rb#L145
Defines the temporary folder to store downloaded files (for API endpoints that have file response). Default to use `Tempfile`.
@return [String]
The time limit for HTTP request in seconds. Default to 0 (never times out).
Defines the username used with HTTP basic authentication.
@return [String]
TLS/SSL
Set this to false to skip verifying SSL certificate when calling API from https server. Default to true.
@note Do NOT set it to false in production code, otherwise you would face multiple types of cryptographic attacks.
@return [true, false]
Public Class Methods
The default Configuration object.
# File lib/cm_api/configuration.rb, line 113 def self.default @@default ||= Configuration.new end
# File lib/cm_api/configuration.rb, line 94 def initialize @scheme = 'http' @host = 'localhost:8080' @base_path = '/cloudera-manager-api' @api_key = {} @api_key_prefix = {} @timeout = 0 @verify_ssl = true @cert_file = nil @key_file = nil @debugging = false @inject_format = false @force_ending_format = false @logger = defined?(Rails) ? Rails.logger : Logger.new(STDOUT) yield(self) if block_given? end
Public Instance Methods
Gets API key (with prefix if set). @param [String] param_name the parameter name of API key auth
# File lib/cm_api/configuration.rb, line 144 def api_key_with_prefix(param_name) if @api_key_prefix[param_name] "#{@api_key_prefix[param_name]} #{@api_key[param_name]}" else @api_key[param_name] end end
Returns Auth Settings hash for api client.
# File lib/cm_api/configuration.rb, line 158 def auth_settings { } end
# File lib/cm_api/configuration.rb, line 131 def base_path=(base_path) # Add leading and trailing slashes to base_path @base_path = "/#{base_path}".gsub(/\/+/, '/') @base_path = "" if @base_path == "/" end
# File lib/cm_api/configuration.rb, line 137 def base_url url = "#{scheme}://#{[host, base_path].join('/').gsub(/\/+/, '/')}".sub(/\/+\z/, '') URI.encode(url) end
Gets Basic Auth token string
# File lib/cm_api/configuration.rb, line 153 def basic_auth_token 'Basic ' + ["#{username}:#{password}"].pack('m').delete("\r\n") end
# File lib/cm_api/configuration.rb, line 117 def configure yield(self) if block_given? end
# File lib/cm_api/configuration.rb, line 126 def host=(host) # remove http(s):// and anything after a slash @host = host.sub(/https?:\/\//, '').split('/').first end
# File lib/cm_api/configuration.rb, line 121 def scheme=(scheme) # remove :// from scheme @scheme = scheme.sub(/:\/\//, '') end


Java Runtime
Full JDK not required
Tomcat 9 requires Java 8 or later
Tomcat 8 requires Java 7 or later
Tomcat 7 requires Java 6 or later
Tomcat Native for OpenSSL support
Unpack an archive
Tomcat Installer for Windows
Package from Linux distribution
Build from source
.zip for Windows
.tar.gz for Linux, OSX etc
Contents is largely the same
Line endings vary
Tomcat Native binary for Windows is included in .zip
Installing from an archive
Windows
Linux
Install from an archive
Display Tomcat home page in browser
bin/
conf/server.xml
Main configuration file
conf/web.xml
Global defaults for all web applications
Syntax defined by Servlet specification
Defines Default and JSP servlets
Can be over-ridden by web application
conf/context.xml
Global defaults for all web applications
Tomcat specific
Can be over-ridden by web application
conf/Catalina/localhost/*.xml
conf/<engine-name>/<host-name>/*.xml
Web-application specific configuration
Always over-rides context.xml in the web application
Name sets context path
conf/logging.properties
Logging configuration
Based on java.util.logging
Extended to be class loader aware
conf/tomcat-users.xml
Configures users for default Realm
Only read at Tomcat start
XML schema file provided
conf/jaspic-providers.xml
Java Authentication Service Provider Interface for Containers
Plug-in authentication modules
Google OAuth most likely use
conf/catalina.properties
Sets system properties
Various Tomcat configuration options set at JVM level
Often used to change default globally but value can still be changed per web application
conf/catalina.policy
Used when running under a security manager
Only lightly tested
Few web applications work under a security manager out of the box
lib/
JAR files required by Tomcat
JARs added here will be visible to all web applications
logs/
Roll over daily except catalina.out
catalina.out - redirected console output
catalina.log - root logger (copied to console)
localhost_access_log - access log for default host
localhost.log - host log
manager.log, host-manager.log - web application log
temp/
Temporary file location used by the JVM
java.io.tmpdir
webapps/
Location of web applications
WARs or directories
Deployed automatically by default
work/
JSP compilation
Session serialization
Windows
Runs as Local System by default
Consider using 'NT AUTHORITY\LocalService'
(no password)
See also Bug 55969
You'll need build-essential
Expand in place, build and copy jsvc to bin
Copy daemon.sh to /etc/init.d/tomcat
Unpacks archive
Creates a service
Automates the manual steps
Provides a GUI to set some basic options
Installing with the Tomcat Installer for Windows
Installing JSVC, the Linux service wrapper
Linux distributions have 'views' on file locations
Tomcat files not all in one location
Often use multiple packages
E.g.: Ubuntu 16.04 LTS and Tomcat 8.0.x
Tend to pick a version and then back-port fixes
Installing from a Linux package
Install from the Installer for Windows
or
Install from a Linux package


Computer Science and Engineering student at Kalinga Institute of Industrial Technology. I do coding especially Python, make websites(front-end), and machine learning with python, and learning new technologies.
Mini-Projects -
Higher-Lower Game
Password-Generator
Black-Jack Game
Future learning goals -
Machine Learning/Artificial Intelligence/Full-stack web developer.
Life moto -
be nice, take less stress, help others and yourself in the best possible way you can, do what you love, hang out, explore yourself.


---
permalink: events/
layout: index
title: Events
show_chownow: true
cover_bgimage_path: /assets/img/events/070916/background.jpg
cover_image_path<EMAIL_ADDRESS>events:
- date: 7.23.16
description: Craftsman Brewing Special Event
url: https://www.facebook.com/events/515674518621273/
upcoming: false
- date: 5.28.16
description: Tap Takeover with Deschutes Brewery
url: https://www.facebook.com/events/238413993190802/
upcoming: false
- date: 3.19.16
description: 7th Anniversary Celebration with Bear Republic
url: https://www.facebook.com/events/1509058916068395/
upcoming: false
- date: 2.27.16
description: Pliny the Younger On Tap 2016
url: https://www.facebook.com/events/218503138500652/
upcoming: false
---


A word from the blog
Doubt fire hits its top sale mark after first month!

Doubt fire hits its top sale mark after first month!


Books
It is worth mentioning that in addition to reading, I spend a good chunk of time on sites like Tekpub, CodeSchool, Railscasts, RubyTapas and occasionally Peepcode.
I wanted to start recording which books I’ve read.
Database:
postgres backup and restore
postgres instant starter
SQL Server 2012 Query Performance Tuning
Delivering Business Intelligence with Microsoft SQL Server 2012
AppDev:
Exceptional Ruby
tmux
vim and vi tips
mastering nginx
RubyMotion
Rails Recipes
Misc:
Ready Player One
-—|-—|— 2012 -—|-—|—
Infrastructure:
Nginx HTTP Server
Pro Linux System Administration (Expert’s Voice in Open Source)
Database:
SQL Server Interview Questions and Answers: For All Database Developers and Developers Administrators
The Little Redis Book
PostgreSQL: Up and Running
Couchbase Manual 1.8
AppDev:
Web Development Recipes
Sinatra: Up and Running
Programming Entity Framework: Code First
Git From The Bottom Up
Heroku Hackers Guide
Professional ASP.NET MVC 4 (Wrox Professional Guides)
Deploying Rails: Automate, Deploy, Scale, Maintain, and Sleep at Night (The Facets of Ruby)
Rails Deep Dive
Practical Performance Profiling: Improving the efficiency of .NET code
MISC
Ship it! A Practical Guide to Successful Software Projects
-—|-—|— 2011 -—|-—|—
Database:
Professional SQL Server 2008 Internals and Troubleshooting
Securing SQL Server: Protecting Your Database from Attackers
SQL Server 2008 Query Performance Tuning Distilled (Expert’s Voice in SQL Server)
Brad’s Sure Guide to SQL Server Maintenance Plans (Dba Handbooks)
How to Become an Exceptional DBA, 2nd Edition
The Red Gate Guide to SQL Server Team-based Development
SQL Server Statistics
Protecting SQL Server Data
Microsoft SQL Server 2008 Management and Administration
SQL Server MVP Deep Dives Vol. 2
PostgreSQL 9.0 Reference Manual – Volume 3: Server Administration Guide
PostgreSQL 9 High Performance
PostgreSQL 9 Admin Cookbook
Writing PostgreSQL Applications
The RavenDB Book
The Little MongoDB Book – Karl Seguin
App Dev:
Pro ASP.NET MVC V2 Framework (Expert’s Voice in .NET)
Professional iPhone Programming with MonoTouch and .NET/C#
Taking Your Talent To The Web – Jeffrey Zeldman
Pragmatic Unit Testing in C# with NUnit
Misc:
Coder to Developer: Tools and Strategies for Delivering Your Software
Defensive Design for the Web: How to improve error messages, help, forms, and other crisis points
Don’t Just Roll The Dice – A usefully short guide to software pricing
Don’t Make Me Think: A Common Sense Approach to Web Usability, 2nd Edition
The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition
The Pragmatic Programmer: From Journeyman to Master
Programming Amazon EC2
Non Technical:
The Art of Deception: Controlling the Human Element of Security
Confessions of a Public Speaker (English and English Edition)
The Cuckoo’s Egg: Tracking a Spy Through the Maze of Computer Espionage
Freakonomics: A Rogue Economist Explores the Hidden Side of Everything (P.S.)
Getting Real
Rockable Personal Branding – Skellie
Secrets of a Buccaneer-Scholar: How Self-Education and the Pursuit of Passion Can Lead to a Lifetime of Success
Start Small, Stay Small: A Developer’s Guide to Launching a Startup
Startups Open Sourced
Zero Day: A Novel


With underline: you can use from other tabs.
A music player on your browser for local files. Made by itchyny.
@CHANGELOG


AMBER Alerts can only be requested by Law Enforcement. A very small percentage of missing child cases qualify for an AMBER Alert.
In Minnesota, the criteria are:
If your child is not issued an AMBER Alert, it does not mean that your child is not missing, that the police are not looking for your child, or that nobody is taking your child’s case seriously. All it means is that law enforcement has decided that AMBER Alert is not the right tool for finding your child and bringing them home. There are still many tools that law enforcement, you, and your team of advocates and volunteers can do to bring your child home.


This diagram illustrates the effects of floating a box ("inner") and how its "sibling" flows alongside it.
A document window is shown, with 8 lines (numbered 1 to 8), each 24px high. Since the "inner" box has been floated to the right, all other text flows around it, including that of the "sibling" box (on lines 1 through 5).
In the following PRE element, each 24 pixel line is simulated by two lines, the second beginning with the appropriate number. Vertical bars represent the left edge of the floated box. The lines, as they appear in the image, contain:
1 Beginning of body contents. Start 2 of outer contents. | Inner 3 Sibling contents. End | contents. 4 of outer contents. End of body 5 contents.
The default text color is black. "Start of outer contents" is red. "Sibling contents" is red. "Inner contents" is blue. "End of outer contents" is red.


Case Type
Status
{{workorder.breakdownAddress}}
Passenger Count
Raised at
# of Flat Tyres
Where is the customer
Additional Comments
{{workorder.summary}}


Starting from Mac OS X 10.5 Objective-C supports an optional Garbage Collection (GC) for code that is explictly compiled to support (or require) garbage collection. The GC system is deprecated in OS X 10.8.
PyObjC does not support the GC system, the core bridge is currently not GC save and using PyObjC in a proces that uses GC is not supported (and the default compilation flags for PyObjC also don’t mention that the code supports GC).
Because GC is not supported you cannot write Screen Savers with PyObjC on Mac OS X 10.6 or 10.7 systems when the system is running with a 64-bit user-space.
The following is an incomplete list of issues that make it impossible to use PyObjC with GC.
The OC_* classes (Objective-C proxies for Python objects) have a -dealloc method, but no -finalize method. This will cause memory leaks when using GC because the Python reference count is never decreased.
Python subclasses of Cocoa classes have a (generated) -dealloc method that cleans up the python state of the object. They don’t have a finalize method, once again causing memory leaks.
The bridge uses NSMapTable instances to store the proxy objects for Python and Objective-C objects (one to get the proxy object for Python objects and one to get the proxy objects for Objective-C objects).
Those currently contain strong references for both keys and values, which means Python objects that have passed the bridge cannot die because their proxy will never be garbage collected.
The NSMapTable instances mentioned in the previous item are likely not used thread safely in GC-ed processes (the use is currently serialized using Python’s GIL)
All Objective-C code needs to be reviewed to check if it is GC-safe.
I don’t expect that PyObjC will ever support GC because Apple has deprecated GC in OS X 10.8, and will likely remove GC support in some future release. It is therefore not worthwhile to spend a signficant amount of time on making PyObjC GC-safe.


Green lines: Average drain over a period
Dark dots: Individual drain samples
Red lines: Device restarts
White text: What happened at a certain time. Zoom in to see.
Pinch with two fingers or double tap to zoom.


The select component was created to emulate the native select element as closely as possible while also providing
more extended styling options. Note that even with the effort already invested in making this component accessible,
it will never match the native select which is directly supported by screenreaders.
To view the styled native select, visit the Form page.


@* * Copyright 2020 HM Revenue & Customs * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. *@ @import uk.gov.hmrc.disguisedremunerationfrontend.views.html.helpers._ @(usersName: String, blocks: Html , dateTime: String, time: String)(implicit messages: UniformMessages[Html], request: Request[AnyContent]) @withCommas(name: String) = @{ if(name.nonEmpty) { s", ${name.trim}," } else { s" $name" } }
@messages("cya-print.p1", dateTime, time)
@blocks


For the record, I'm still learning how to do this whole "life" thing.

In continuing to examine my assumptions, I've started to see the "black boxes" in my thinking – swaths of my perception that I'm blind to. Sometimes, they exist because I have inaccurate data about a project that keeps me from seeing the reality of whats going on, but other times it's myself that I can't see, which keeps me from being in-tune with how my actions affect what I'm doing or the people around me.
Recently, I had one of those big black blind boxes planted directly over a particular relationship with a teammate. I was completely unable to see that I had done nothing to build trust with them, but was instead micromanaging their portion of the project, and making them feel disempowered to bring their expertise to the table. The surprising thing to me wasn't that I was basically managing the project very poorly – I am very aware of my baby-level management skills – what surprised me was that, yet again, I couldn't see it. It was only after my interactions were played back to me by another teammate that I saw how incredibly rude and arrogant I had been – in what I thought was the best interest of the project.
Black boxes are sneaky – they don't show themselves on their own, until it's too late. I need to learn how to hold a mental candle up to everything I do, so that I can see, if not the actual wrong-ness of my actions, at least the black boxes themselves. If I can see the boxes, I'll be able to work backwards and find out what I'm missing.
But that's not the point.
We all have black boxes in our minds. We all struggle to see how our actions affect others, how they affect projects we're working on, and how they affect our own selves. That's something I will always struggle with, and I hope I'll continue to make progress and get better at uncovering those boxes.
The point is: what do you do once you've found them? That's where humility becomes the most crucial thing of all.
My actions towards my teammate were really wrong. I felt I was in the right, arguing for the betterment of the project at hand, but in the process, I really hurt someone by making them feel that they had nothing to contribute. I walked all over them in the interest of "making things better". At the time, I didn't think that it would be possible to heal that relationship in a way that wouldn't leave a long, awkward aftertaste.
After some wonderful soul-searching with another teammate, I was counseled to simply humbly make amends, let that feeling of asshole-being really sink in and sting, think of the situation from the other's perspective, and genuinely admit to being that asshole that I never wanted to be.
Super simple, kindergarten human-being 101, there.
All I can say is that genuine humility, without expectation of forgiveness or "results", is miraculous. The amount of healing that can be had, both for your own being and for a relationship, by simply getting down and being vulnerable in your own shortcomings, is incredible. My teammate and I are on much better terms than we ever had been.
By focusing on humility in my management and relationships, I hope I'll be able to more clearly see the black boxes. At this point, I'm pretty confident that humility is the secret to the whole "life" thing.
Go forth and be humble, folks.
Lately, I've been busy.
I currently run MUX, a local music venue in Richland Wa. We focus on regional and local independent music, producing between one and three shows a month. I've been learning a ton – not only about the music industry, booking, production, and promotion, but about myself.
Assumptions are essential for effective life-living and thing-building. You can't do any one thing without having some preconcieved idea about what you should do, or at least how you should learn to do that thing. However, assumptions are only healthy when they are constantly challenged in your own head.
For example: most MUX shows don't sell many presale tickets. We generally announce the show three weeks in advance, and offer cheaper presale tickets right away. One or two tickets will sell in the first two weeks, but the majority of the ticket sales will be in the last two days before the show. This is generally fine, aside from the fact that it's difficult to figure out how many people will show up ahead of time.
Two weeks ago, we put on an outdoor festival called TriFest, in connection with a local art/design/tech/entrepreneurship conference called TriConf. Ten bands (all regional medium-sized bands) played over the two nights of TriConf. Two-day wristbands were $35 presale, $40 day of show, and TriConf attendees received free wristbands. Leading up to the festival, wristband sales looked much the same – one or two wristbands sold in the first two weeks of promotion, and a couple more in the last week.
The first night of the show, almost nobody showed up. The attendees from TriConf trickled in and out, but a grand total of a dozen festival-goers made it out that night. It felt like an utter failure, and I didn't know why.
Later that night, I was taken aside by a good friend and fellow MUX teammate. He told me that he honestly felt that the ticket price had scared off a lot of folks, and that would account for the dissapointing turnout that night. This didn't come as a shock to me – I had worried about the ticket price – but I realized that my unchallenged assumptions about ticket sale patterns had prevented me from seeing that the price was too high, and people weren't going to come.
There's a good cliche out there: "you can't know what you don't know". Assumptions work off the worst side of that – you feel that you have a grasp on whatever's at hand, but left unchallenged, you're completely blind to any potential problems that your assumptions don't account for.
I'm seeking to break down that wall for myself. I need to be able to see the holes in my assumptions and fill them with the information that is already there, waiting for me to ask the right questions to discover it.
Here's my plan.
- start asking myself "what if" questions to find parts of my projects that haven't been considered, and then
- learn to find people who may have honest perspective on my projects and ask probing questions to gain that perspective myself.
- to learn to channel the "irrational" anxious feelings that come with new projects into constructive critiscism of my assumptions
- to document my failures and reference them often in relation to my current projects
In the end, we made the second night of TriFest free to all, and promoted the crap out of it that day, thanks to feedback and ideas from another member of the MUX team. By personally asking people to invite all their friends, writing a blog post on the MUX site about why we made the second night free, and pushing it out on all the interwubs, 300 people came to that night's show. That's great, but had I been able to understand how people percieved the ticket pricing ahead of time, the whole weekend could have been packed out, and I could have been selling tickets at greater than $0.
I'd crave your thoughts.  Has hindsight enlightened your current planning process? What are some methods that you use to gain perspective when you are planning and executing your projects?
<3
"...And we pray, not for new
earth or heaven, but to be quiet
in heart, and in eye clear.
What we need is here."– Wendell Berry
We're really lucky bastards. Here in the comfy bubble of the tech world, there's practically no glass ceiling we won't eventually smash through. I've been blessed with a company I can believe in, amazing teammates, good health, and a wonderful place to live surrounded by pristine nature. I live a life filled with abundance, for which I am extremely grateful. If you ever catch me complaining, you have my permission to slap some sense into me.
I firmly believe that we cannot afford to become complacent in our position, but to use it to do the greatest good we can in the short time we have. As such, I am setting a personal bar for myself this Thanksgiving by giving $200 to a different cause each month. Here's the list I've got so far (If you know of a cause that you think should be on my list, please get in touch with me):
- Nov: charity: water
- Dec: World Vision Micro Loan
- Jan: Let's Respond
- Feb: Amazima
- Mar: Doctors Without Borders
- Apr: Not For Sale
- May:
- Jun:
- Jul:
- Aug:
- Sep:
- Oct:
I'd really like you to join me in this endeavor. If you do, please let me know, and I'll link you from this post.
Together, we can use our privileged position to do a little good in the world.
So, here it goes.
A couple things happened at Realtime Conf that sparked my move to the #indieweb. One of them was a talk given by Amber Case called "The Open Web and the Opportunity of Now". You need to simply sit down and watch it, but the tl;dr goes like "get out there, use what's already been written, own your data, and build cool things".
As soon as I heard that talk, I knew I needed to sit down and finally get my online presence wrangled together, starting with my personal blog. My persona online has been growing and becoming more fragmented very rapidly, which, despite the convenience of all those accounts and services, still left me feeling unsettled and uneasy. So far I've:
- moved this blog off of tumblr
- quit facebook
- downloaded tons of data from many of my social sites, and
- figured out a plan for finally lassoing my persona into one place, ike.io.
The second thing that started this 'homesteading' itch (have you watched the talk yet?), was more of a nagging zeitgeist feeling. I haven't nailed it down, but I have this notion that we're embarking on something big right now. I think we'd better buckle up.
After putting it off for a long, long time, I have finally bitten the bullet and will start my obligatory personal tech blog.
The signal/noise ratio is impressively high out there on the interwebs, so I hope to hold a laser focus on valuable, personal editorial content here.
Life’s too short for bad blogs.


| Affiliation |
| none |
Value : none
|
| outcast |
Value : outcast
|
| member |
Value : member
|
| admin |
Value : admin
|
| owner |
Value : owner
|
| ContactSubscription |
| to |
Value : to
|
| from |
Value : from
|
| both |
Value : both
|
| none |
Value : none
|
| Direction |
| in |
Value : in
|
| out |
Value : out
|
| MessageState |
| SENDING |
Value : sending
|
| SENT |
Value : sent
|
| RECIPIENT_RECEIVED |
Value : recipientReceived
|
| RECIPIENT_SEEN |
Value : recipientSeen
|
| LogLevel |
| Disabled |
| Error |
| Warn |
| Info |
| Debug |
| Presence |
| present |
Value : present
|
| unavailable |
Value : unavailable
|
| away |
Value : away
|
| Role |
| none |
Value : none
|
| visitor |
Value : visitor
|
| participant |
Value : participant
|
| moderator |
Value : moderator
|
| SubscriptionAction |
| PENDING_REQUEST |
| SHOW_BLOCK_ACTIONS |
| NO_PENDING_REQUEST |


{% extends "sphene/base.html" %}
{% block content %}
Error 500 - Internal Error
Sorry, an internal error happened while processing your request. You might want to go to the last page and try again.
An email has been generated to notify the admin of this site about the problem.
{% endblock %}


Learning Competencies
Phase 0 - Week 1
Thinking About Time
May 7th 2015
Learning Competencies:
- Research time management and productivity
- Time management
- Time management is the process of organizing and planning how much time you spend on specific activities. Invest some time in our comprehensive collection of time management articles to learn about managing your own time more efficiently, and save yourself time in the future.
- Greater productivity and efficiency
- A better professional reputation.
- Less Stress
- Increased opportunities for advancement
- Greater opportunities to achieve important life and career goals.
- Missed deadlines
- Inefficient workflow
- Poor work quality
- A poor professional repuration and a stalled career
- Higher stress levels
- Productivity
- A measure of the efficiency of a person in converting inputs into outputs.
- Explain "Time Boxing" and explain how to use it
- Time Box
- A previously agreed period of time during which a person or a team works steadily towards completion of some goal. Rather than to continuously work until the goal is reached and evaluating the time taken, the timebox approach consists of stopping work when the time limit is reached and evaluating what was accomplished.
Time boxing depends on varying the time scales. A common technique that is used is the "pomdoro technique". This technique organizes personal work around 25-minute timeboxes with a 5 minute work break.
Always stop work at the end of the time box and review your progress. Determine whether your goal has been met, or partially met if it included multiple tasks.
Your Command Line
May 7th 2015
Learning Competencies:
- Explain what the "shell" is
- Describe "bash"
- As a user interface
- As a programming environment
A Shell is any user interface to the UNIX operating system. Any program that takes input from the user, translates it into instructions that the operating system can understand, and conveys the operating system's output back to the user.
A Bash is a Unix shell that acts as a software replacement for the Bourne shell. Bash is a command processor that typically runs in a text window where the user types commands that cause actions.
There are two ways to use bash:
- Identify your location
- Navigate between directories
- Move, rename, and copy items
- Create new and delete existing directories and files
- Open, view, or stream a file
- Find and look inside files
- Get Help
In order to identify my location, I would have to use the (pwd) command. This stands for Paths, Folders, and Directories
To navigate between directories, use the (cd) command. This stands for Change Directory.
Rename: (mv) Move: (mv) Copy: (cp)
Making an empty file: (touch) Make Directory: (mkdir) Delete Directory: (rmdir)
View a file: (less, MORE) Stream a file: (cat)
Finding files: (find, DIR-R) Looking inside files: (find, DIR-R)
Getting help: (apropos, HELP)


ELS events
Creative Writing (30 points)
No. of Pools: 4
No. Of Teams from each Pool: 2 (max 2 participants in each team)
Appreciation Trophy: Best Writer, Short Fiction Story
- Each team will submit two entries which may consist of multiple compositions.
- Total time allowed is 2 hours.
- There will also be a prescribed word count.
- Total points for each pool would be the sum of points of both teams from the pool.
- Decision of the judge will be final.
Dumb Charades (30 points)
No. of Pools: 4
- Open participation for Prelims
- 3 members in a team
- Minimum 4 from a Pool
- 3 teams will advance beyond the prelims
- There will be several rounds including Blitz, Bidding, Handicap, Triple DumbC and a few surprise
rounds.
Word Games (30 points)
No. of Pools: 4
- Written Round
- Open participation
- Duration of 2 hours
- A minimum of 2 teams from each pool consisting of max 3 members each
JAM (30 points)
No. of Pools: 4
- 4 participants from each pool out of which at least 2 should be Y16 and 2 should be from Y15
and older batches.
- There will be at least two JAMs and two HAMs. One JAM and one HAM will be for Y16 participants only. One JAM and one HAM will be for Y15 or older participants only.
- Each JAM will be worth 60 points and each HAM will be worth 30 points. Points will be awarded in the following fashion: (for each JAM/ HAM table)
- 100% for 1st ranked pool
- 60% for 2nd
- 30% for 3rd
- 15% for 4th
- 5% for 5th
- 0% for any pool that doesn’t participate at a table.
Ranks will be decided by the sum of the points obtained by both the participants from a pool at a table
Decision of the JAMmaster will be final and binding on all participants during the event.
The Coordinators of the Club will be Spotter
Poetry Slam (30 points)
No. of Pools: 4
Rules
- All entries need to be original and should be submitted latest on Feb 10, 11.59 pm
- Number of entries per pool is not restricted, but must have at least one Y16 entry
- The judge will select top 3 entries from each pool for performing in the final round.
- The time limit for each recitation is 5 minutes
- Participants may carry a piece of paper or phone to which they may refer to while recitation.