Ganeti is a virtualization cluster management software. You are expected
to be a system administrator familiar with your Linux distribution and
the Xen or KVM virtualization environments before using it.
The various components of Ganeti all have man pages and interactive
help. This manual though will help you getting familiar with the system
by explaining the most common operations, grouped by related use.
After a terminology glossary and a section on the prerequisites needed
to use this manual, the rest of this document is divided in sections
for the different targets that a command affects: instance, nodes, etc.
This section provides a small introduction to Ganeti terminology, which
might be useful when reading the rest of the document.
A set of machines (nodes) that cooperate to offer a coherent, highly
available virtualization service under a single administration domain.
A physical machine which is member of a cluster. Nodes are the basic
cluster infrastructure, and they don’t need to be fault tolerant in
order to achieve high availability for instances.
Node can be added and removed (if they host no instances) at will from
the cluster. In a HA cluster and only with HA instances, the loss of any
single node will not cause disk data loss for any instance; of course,
a node crash will cause the crash of its primary instances.
A node belonging to a cluster can be in one of the following roles at a
given time:
- master node, which is the node from which the cluster is controlled
- master candidate node, only nodes in this role have the full cluster
configuration and knowledge, and only master candidates can become the
master node
- regular node, which is the state in which most nodes will be on
bigger clusters (>20 nodes)
- drained node, nodes in this state are functioning normally but the
cannot receive new instances; the intention is that nodes in this role
have some issue and they are being evacuated for hardware repairs
- offline node, in which there is a record in the cluster
configuration about the node, but the daemons on the master node will
not talk to this node; any instances declared as having an offline
node as either primary or secondary will be flagged as an error in the
cluster verify operation
Depending on the role, each node will run a set of daemons:
- the ganeti-noded daemon, which controls the manipulation of
this node’s hardware resources; it runs on all nodes which are in a
cluster
- the ganeti-confd daemon (Ganeti 2.1+) which runs on all
nodes, but is only functional on master candidate nodes; this daemon
can be disabled at configuration time if you don’t need its
functionality
- the ganeti-rapi daemon which runs on the master node and
offers an HTTP-based API for the cluster
- the ganeti-masterd daemon which runs on the master node and
allows control of the cluster
Beside the node role, there are other node flags that influence its
behaviour:
- the master_capable flag denotes whether the node can ever become a
master candidate; setting this to ‘no’ means that auto-promotion will
never make this node a master candidate; this flag can be useful for a
remote node that only runs local instances, and having it become a
master is impractical due to networking or other constraints
- the vm_capable flag denotes whether the node can host instances or
not; for example, one might use a non-vm_capable node just as a master
candidate, for configuration backups; setting this flag to no
disallows placement of instances of this node, deactivates hypervisor
and related checks on it (e.g. bridge checks, LVM check, etc.), and
removes it from cluster capacity computations
A virtual machine which runs on a cluster. It can be a fault tolerant,
highly available entity.
An instance has various parameters, which are classified in three
categories: hypervisor related-parameters (called hvparams), general
parameters (called beparams) and per network-card parameters (called
nicparams). All these parameters can be modified either at instance
level or via defaults at cluster level.
The are multiple options for the storage provided to an instance; while
the instance sees the same virtual drive in all cases, the node-level
configuration varies between them.
There are several disk templates you can choose from:
- diskless
- The instance has no disks. Only used for special purpose operating
systems or for testing.
- file *
- The instance will use plain files as backend for its disks. No
redundancy is provided, and this is somewhat more difficult to
configure for high performance.
- sharedfile *
- The instance will use plain files as backend, but Ganeti assumes that
those files will be available and in sync automatically on all nodes.
This allows live migration and failover of instances using this
method.
- plain
- The instance will use LVM devices as backend for its disks. No
redundancy is provided.
- drbd
Note
This is only valid for multi-node clusters using DRBD 8.0+
A mirror is set between the local node and a remote one, which must be
specified with the second value of the –node option. Use this option
to obtain a highly available instance that can be failed over to a
remote node should the primary one fail.
Note
Ganeti does not support DRBD stacked devices:
DRBD stacked setup is not fully symmetric and as such it is
not working with live migration.
- rbd
- The instance will use Volumes inside a RADOS cluster as backend for its
disks. It will access them using the RADOS block device (RBD).
- gluster *
- The instance will use a Gluster volume for instance storage. Disk
images will be stored in the top-level ganeti/ directory of the
volume. This directory will be created automatically for you.
- ext
- The instance will use an external storage provider. See
ganeti-extstorage-interface(7) for how to implement one.
Note
Disk templates marked with an asterisk require Ganeti to access the
file system. Ganeti will refuse to do so unless you whitelist the
relevant paths in /etc/ganeti/file-storage-paths.
The default paths used by Ganeti are:
| Disk template |
Default path |
| file |
/srv/ganeti/file-storage |
| sharedfile |
/srv/ganeti/shared-file-storage |
| gluster |
/var/run/ganeti/gluster |
Those paths can be changed at gnt-cluster init time. See
gnt-cluster(8) for details.
A framework for using external (user-provided) scripts to compute the
placement of instances on the cluster nodes. This eliminates the need to
manually specify nodes in instance add, instance moves, node evacuate,
etc.
In order for Ganeti to be able to use these scripts, they must be place
in the iallocator directory (usually lib/ganeti/iallocators under
the installation prefix, e.g. /usr/local).
An instance has a primary and depending on the disk configuration, might
also have a secondary node. The instance always runs on the primary node
and only uses its secondary node for disk replication.
Similarly, the term of primary and secondary instances when talking
about a node refers to the set of instances having the given node as
primary, respectively secondary.
While not directly visible by an end-user, it’s useful to know that a
basic cluster operation (e.g. starting an instance) is represented
internally by Ganeti as an OpCode (abbreviation from operation
code). These OpCodes are executed as part of a Job. The OpCodes in a
single Job are processed serially by Ganeti, but different Jobs will be
processed (depending on resource availability) in parallel. They will
not be executed in the submission order, but depending on resource
availability, locks and (starting with Ganeti 2.3) priority. An earlier
job may have to wait for a lock while a newer job doesn’t need any locks
and can be executed right away. Operations requiring a certain order
need to be submitted as a single job, or the client must submit one job
at a time and wait for it to finish before continuing.
For example, shutting down the entire cluster can be done by running the
command gnt-instance shutdown --all, which will submit for each
instance a separate job containing the “shutdown instance” OpCode.
You need to have your Ganeti cluster installed and configured before you
try any of the commands in this document. Please follow the
Ganeti installation tutorial for instructions on how to do that.
The add operation might seem complex due to the many parameters it
accepts, but once you have understood the (few) required parameters and
the customisation capabilities you will see it is an easy operation.
The add operation requires at minimum five parameters:
- the OS for the instance
- the disk template
- the disk count and size
- the node specification or alternatively the iallocator to use
- and finally the instance name
The OS for the instance must be visible in the output of the command
gnt-os list and specifies which guest OS to install on the instance.
The disk template specifies what kind of storage to use as backend for
the (virtual) disks presented to the instance; note that for instances
with multiple virtual disks, they all must be of the same type.
The node(s) on which the instance will run can be given either manually,
via the -n option, or computed automatically by Ganeti, if you have
installed any iallocator script.
With the above parameters in mind, the command is:
$ gnt-instance add \
-n TARGET_NODE:SECONDARY_NODE \
-o OS_TYPE \
-t DISK_TEMPLATE -s DISK_SIZE \
INSTANCE_NAME
The instance name must be resolvable (e.g. exist in DNS) and usually
points to an address in the same subnet as the cluster itself.
The above command has the minimum required options; other options you
can give include, among others:
- The maximum/minimum memory size (-B maxmem, -B minmem)
(-B memory can be used to specify only one size)
- The number of virtual CPUs (-B vcpus)
- Arguments for the NICs of the instance; by default, a single-NIC
instance is created. The IP and/or bridge of the NIC can be changed
via --net 0:ip=IP,link=BRIDGE
See ganeti-instance(8) for the detailed option list.
For example if you want to create an highly available instance, with a
single disk of 50GB and the default memory size, having primary node
node1 and secondary node node3, use the following command:
$ gnt-instance add -n node1:node3 -o debootstrap -t drbd -s 50G \
instance1
There is a also a command for batch instance creation from a
specification file, see the batch-create operation in the
gnt-instance manual page.
Removing an instance is even easier than creating one. This operation is
irreversible and destroys all the contents of your instance. Use with
care:
$ gnt-instance remove INSTANCE_NAME
Instances are automatically started at instance creation time. To
manually start one which is currently stopped you can run:
$ gnt-instance startup INSTANCE_NAME
Ganeti will start an instance with up to its maximum instance memory. If
not enough memory is available Ganeti will use all the available memory
down to the instance minimum memory. If not even that amount of memory
is free Ganeti will refuse to start the instance.
Note, that this will not work when an instance is in a permanently
stopped state offline. In this case, you will first have to
put it back to online mode by running:
$ gnt-instance modify --online INSTANCE_NAME
The command to stop the running instance is:
$ gnt-instance shutdown INSTANCE_NAME
If you want to shut the instance down more permanently, so that it
does not require dynamically allocated resources (memory and vcpus),
after shutting down an instance, execute the following:
$ gnt-instance modify --offline INSTANCE_NAME
Warning
Do not use the Xen or KVM commands directly to stop
instances. If you run for example xm shutdown or xm destroy
on an instance Ganeti will automatically restart it (via
the ganeti-watcher(8) command which is launched via cron).
Instances can also be shutdown by the user from within the instance, in
which case they will marked accordingly and the
ganeti-watcher(8) will not restart them. See
gnt-cluster(8) for details.
There are two ways to get information about instances: listing
instances, which does a tabular output containing a given set of fields
about each instance, and querying detailed information about a set of
instances.
The command to see all the instances configured and their status is:
The command can return a custom set of information when using the -o
option (as always, check the manpage for a detailed specification). Each
instance will be represented on a line, thus making it easy to parse
this output via the usual shell utilities (grep, sed, etc.).
To get more detailed information about an instance, you can run:
$ gnt-instance info INSTANCE
which will give a multi-line block of information about the instance,
it’s hardware resources (especially its disks and their redundancy
status), etc. This is harder to parse and is more expensive than the
list operation, but returns much more detailed information.
Ganeti will always make sure an instance has a value between its maximum
and its minimum memory available as runtime memory. As of version 2.6
Ganeti will only choose a size different than the maximum size when
starting up, failing over, or migrating an instance on a node with less
than the maximum memory available. It won’t resize other instances in
order to free up space for an instance.
If you find that you need more memory on a node any instance can be
manually resized without downtime, with the command:
$ gnt-instance modify -m SIZE INSTANCE_NAME
The same command can also be used to increase the memory available on an
instance, provided that enough free memory is available on its node, and
the specified size is not larger than the maximum memory size the
instance had when it was first booted (an instance will be unable to see
new memory above the maximum that was specified to the hypervisor at its
boot time, if it needs to grow further a reboot becomes necessary).
You can create a snapshot of an instance disk and its Ganeti
configuration, which then you can backup, or import into another
cluster. The way to export an instance is:
$ gnt-backup export -n TARGET_NODE INSTANCE_NAME
The target node can be any node in the cluster with enough space under
/srv/ganeti to hold the instance image. Use the --noshutdown
option to snapshot an instance without rebooting it. Note that Ganeti
only keeps one snapshot for an instance - any previous snapshot of the
same instance existing cluster-wide under /srv/ganeti will be
removed by this operation: if you want to keep them, you need to move
them out of the Ganeti exports directory.
Importing an instance is similar to creating a new one, but additionally
one must specify the location of the snapshot. The command is:
$ gnt-backup import -n TARGET_NODE \
--src-node=NODE --src-dir=DIR INSTANCE_NAME
By default, parameters will be read from the export information, but you
can of course pass them in via the command line - most of the options
available for the command gnt-instance add are supported here
too.
There is a possibility to import a foreign instance whose disk data is
already stored as LVM volumes without going through copying it: the disk
adoption mode.
For this, ensure that the original, non-managed instance is stopped,
then create a Ganeti instance in the usual way, except that instead of
passing the disk information you specify the current volumes:
$ gnt-instance add -t plain -n HOME_NODE ... \
--disk 0:adopt=lv_name[,vg=vg_name] INSTANCE_NAME
This will take over the given logical volumes, rename them to the Ganeti
standard (UUID-based), and without installing the OS on them start
directly the instance. If you configure the hypervisor similar to the
non-managed configuration that the instance had, the transition should
be seamless for the instance. For more than one disk, just pass another
disk parameter (e.g. --disk 1:adopt=...).
The kernel that instances uses to bootup can come either from the node,
or from instances themselves, depending on the setup.
With Xen PVM, there are three options.
First, you can use a kernel from the node, by setting the hypervisor
parameters as such:
- kernel_path to a valid file on the node (and appropriately
initrd_path)
- kernel_args optionally set to a valid Linux setting (e.g. ro)
- root_path to a valid setting (e.g. /dev/xvda1)
- bootloader_path and bootloader_args to empty
Alternatively, you can delegate the kernel management to instances, and
use either pvgrub or the deprecated pygrub. For this, you must
install the kernels and initrds in the instance and create a valid GRUB
v1 configuration file.
For pvgrub (new in version 2.4.2), you need to set:
- kernel_path to point to the pvgrub loader present on the node
(e.g. /usr/lib/xen/boot/pv-grub-x86_32.gz)
- kernel_args to the path to the GRUB config file, relative to the
instance (e.g. (hd0,0)/grub/menu.lst)
- root_path must be empty
- bootloader_path and bootloader_args to empty
While pygrub is deprecated, here is how you can configure it:
- bootloader_path to the pygrub binary (e.g. /usr/bin/pygrub)
- the other settings are not important
More information can be found in the Xen wiki pages for pvgrub and pygrub.
For KVM also the kernel can be loaded either way.
For loading the kernels from the node, you need to set:
- kernel_path to a valid value
- initrd_path optionally set if you use an initrd
- kernel_args optionally set to a valid value (e.g. ro)
If you want instead to have the instance boot from its disk (and execute
its bootloader), simply set the kernel_path parameter to an empty
string, and all the others will be ignored.
Ganeti used to describe NICs of an Instance with an IP, a MAC, a connectivity
link and mode. This had three major shortcomings:
- there was no easy way to assign a unique IP to an instance
- network info (subnet, gateway, domain, etc.) was not available on target
node (kvm-ifup, hooks, etc)
- one should explicitly pass L2 info (mode, and link) to every NIC
Plus there was no easy way to get the current networking overview (which
instances are on the same L2 or L3 network, which IPs are reserved, etc).
All the above required an external management tool that has an overall view
and provides the corresponding info to Ganeti.
gnt-network aims to support a big part of this functionality inside Ganeti and
abstract the network as a separate entity. Currently, a Ganeti network
provides the following:
- A single IPv4 pool, subnet and gateway
- Connectivity info per nodegroup (mode, link)
- MAC prefix for each NIC inside the network
- IPv6 prefix/Gateway related to this network
- Tags
IP pool management ensures IP uniqueness inside this network. The user can
pass ip=pool,network=test and will:
- Get the first available IP in the pool
- Inherit the connectivity mode and link of the network’s netparams
- NIC will obtain the MAC prefix of the network
- All network related info will be available as environment variables in
kvm-ifup scripts and hooks, so that they can dynamically manage all
networking-related setup on the host.
To create a network do:
# gnt-network add --network=<IP_ADDRESS>/24 --gateway=<IP_ADDRESS> test
Please see all other available options (–add-reserved-ips, –mac-prefix,
–network6, –gateway6, –tags).
Currently, IPv6 info is not used by Ganeti itself. It only gets exported
to NIC configuration scripts and hooks via environment variables.
To make this network available on a nodegroup you should specify the
connectivity mode and link during connection:
# gnt-network connect test bridged br100 default nodegroup1
To add a NIC inside this network:
# gnt-instance modify --net -1:add,ip=pool,network=test inst1
This will let a NIC obtain a unique IP inside this network, and inherit the
nodegroup’s netparams (bridged, br100). IP here is optional. If missing the
NIC will just get the L2 info.
To move an existing NIC from a network to another and remove its IP:
# gnt-instance modify --net -1:ip=none,network=test1 inst1
This will release the old IP from the old IP pool and the NIC will inherit the
new nicparams.
On the above actions there is a extra option –no-conflicts-ckeck. This
does not check for conflicting setups. Specifically:
- When a network is added, IPs of nodes and master are not being checked.
- When connecting a network on a nodegroup, IPs of instances inside this
nodegroup are not checked whether they reside inside the subnet or not.
- When specifying explicitly a IP without passing a network, Ganeti will not
check if this IP is included inside any available network on the nodegroup.
All the aforementioned steps assure NIC configuration from the Ganeti
perspective. Of course this has nothing to do, how the instance eventually will
get the desired connectivity (IPv4, IPv6, default routes, DNS info, etc) and
where will the IP resolve. This functionality is managed by the external
components.
Let’s assume that the VM will need to obtain a dynamic IP via DHCP, get a SLAAC
address, and use DHCPv6 for other configuration information (in case RFC-6106
is not supported by the client, e.g. Windows). This means that the following
external services are needed:
- A DHCP server
- An IPv6 router sending Router Advertisements
- A DHCPv6 server exporting DNS info
- A dynamic DNS server
These components must be configured dynamically and on a per NIC basis.
The way to do this is by using custom kvm-ifup scripts and hooks.
The snf-network package [1,3] includes custom scripts that will provide the
aforementioned functionality. kvm-vif-bridge and vif-custom is an
alternative to kvm-ifup and vif-ganeti that take into account all network
info being exported. Their actions depend on network tags. Specifically:
dns: will update an external DDNS server (nsupdate on a bind server)
ip-less-routed: will setup routes, rules and proxy ARP
This setup assumes a pre-existing routing table along with some local
configuration and provides connectivity to instances via an external
gateway/router without requiring nodes to have an IP inside this network.
private-filtered: will setup ebtables rules to ensure L2 isolation on a
common bridge. Only packets with the same MAC prefix will be forwarded to the
corresponding virtual interface.
nfdhcpd: will update an external DHCP server
snf-network works with nfdhcpd [2,3]: a custom user space DHCP
server based on NFQUEUE. Currently, nfdhcpd replies on BOOTP/DHCP requests
originating from a tap or a bridge. Additionally in case of a routed setup it
provides a ra-stateless configuration by responding to router and neighbour
solicitations along with DHCPv6 requests for DNS options. Its db is
dynamically updated using text files inside a local dir with inotify
(snf-network just adds a per NIC binding file with all relevant info if the
corresponding network tag is found). Still we need to mangle all these
packets and send them to the corresponding NFQUEUE.
Currently the following things are some know weak points of the gnt-network
design and implementation:
- Cannot define a network without an IP pool
- The pool defines the size of the network
- Reserved IPs must be defined explicitly (inconvenient for a big range)
- Cannot define an IPv6 only network
There are much fewer node operations available than for instances, but
they are equivalently important for maintaining a healthy cluster.
It is at any time possible to extend the cluster with one more node, by
using the node add operation:
If the cluster has a replication network defined, then you need to pass
the -s REPLICATION_IP parameter to this option.
A variation of this command can be used to re-configure a node if its
Ganeti configuration is broken, for example if it has been reinstalled
by mistake:
$ gnt-node add --readd EXISTING_NODE
This will reinitialise the node as if it’s been newly added, but while
keeping its existing configuration in the cluster (primary/secondary IP,
etc.), in other words you won’t need to use -s here.
A node can be in different roles, as explained in the
Ganeti terminology section. Promoting a node to the master role is
special, while the other roles are handled all via a single command.
If you want to promote a different node to the master role (for whatever
reason), run on any other master-candidate node the command:
$ gnt-cluster master-failover
and the node you ran it on is now the new master. In case you try to run
this on a non master-candidate node, you will get an error telling you
which nodes are valid.
The gnt-node modify command can be used to select a new role:
# change to master candidate
$ gnt-node modify -C yes NODE
# change to drained status
$ gnt-node modify -D yes NODE
# change to offline status
$ gnt-node modify -O yes NODE
# change to regular mode (reset all flags)
$ gnt-node modify -O no -D no -C no NODE
Note that the cluster requires that at any point in time, a certain
number of nodes are master candidates, so changing from master candidate
to other roles might fail. It is recommended to either force the
operation (via the --force option) or first change the number of
master candidates in the cluster - see Standard operations.
There are two steps of moving instances off a node:
- moving the primary instances (actually converting them into secondary
instances)
- moving the secondary instances (including any instances converted in
the step above)
For this step, you can use either individual instance move
commands (as seen in Changing the primary node) or the bulk
per-node versions; these are:
$ gnt-node migrate NODE
$ gnt-node evacuate -s NODE
Note that the instance “move” command doesn’t currently have a node
equivalent.
Both these commands, or the equivalent per-instance command, will make
this node the secondary node for the respective instances, whereas their
current secondary node will become primary. Note that it is not possible
to change in one step the primary node to another node as primary, while
keeping the same secondary node.
For the evacuation of secondary instances, a command called
gnt-node evacuate is provided and its syntax is:
$ gnt-node evacuate -I IALLOCATOR_SCRIPT NODE
$ gnt-node evacuate -n DESTINATION_NODE NODE
The first version will compute the new secondary for each instance in
turn using the given iallocator script, whereas the second one will
simply move all instances to DESTINATION_NODE.
Once a node no longer has any instances (neither primary nor secondary),
it’s easy to remove it from the cluster:
$ gnt-node remove NODE_NAME
This will deconfigure the node, stop the ganeti daemons on it and leave
it hopefully like before it joined to the cluster.
The gnt-node modify -s command can be used to change the
secondary IP of a node. This operation can only be performed if:
- No instance is active on the target node
- The new target IP is reachable from the master’s secondary IP
Also this operation will not allow to change a node from single-homed
(same primary and secondary ip) to multi-homed (separate replication
network) or vice versa, unless:
- The target node is the master node and –force is passed.
- The target cluster is single-homed and the new primary ip is a change
to single homed for a particular node.
- The target cluster is multi-homed and the new primary ip is a change
to multi homed for a particular node.
For example to do a single-homed to multi-homed conversion:
$ gnt-node modify --force -s SECONDARY_IP MASTER_NAME
$ gnt-node modify -s SECONDARY_IP NODE1_NAME
$ gnt-node modify -s SECONDARY_IP NODE2_NAME
$ gnt-node modify -s SECONDARY_IP NODE3_NAME
...
The same commands can be used for multi-homed to single-homed except the
secondary IPs should be the same as the primaries for each node, for
that case.
When using LVM (either standalone or with DRBD), it can become tedious
to debug and fix it in case of errors. Furthermore, even file-based
storage can become complicated to handle manually on many hosts. Ganeti
provides a couple of commands to help with automation.
This is a command specific to LVM handling. It allows listing the
logical volumes on a given node or on all nodes and their association to
instances via the volumes command:
$ gnt-node volumes
Node PhysDev VG Name Size Instance
node1 /dev/sdb1 xenvg e61fbc97-….disk0 512M instance17
node1 /dev/sdb1 xenvg ebd1a7d1-….disk0 512M instance19
node2 /dev/sdb1 xenvg 0af08a3d-….disk0 512M instance20
node2 /dev/sdb1 xenvg cc012285-….disk0 512M instance16
node2 /dev/sdb1 xenvg f0fac192-….disk0 512M instance18
The above command maps each logical volume to a volume group and
underlying physical volume and (possibly) to an instance.
New in version 2.1.
Starting with Ganeti 2.1, a new storage framework has been implemented
that tries to abstract the handling of the storage type the cluster
uses.
First is listing the backend storage and their space situation:
$ gnt-node list-storage
Node Type Name Size Used Free Allocatable
node1 lvm-vg xenvg 3.6T 0M 3.6T Y
node2 lvm-vg xenvg 3.6T 0M 3.6T Y
node3 lvm-vg xenvg 3.6T 2.0G 3.6T Y
The default is to list LVM physical volumes. It’s also possible to list
the LVM volume groups:
$ gnt-node list-storage -t lvm-vg
Node Type Name Size Used Free Allocatable
node1 lvm-vg xenvg 3.6T 0M 3.6T Y
node2 lvm-vg xenvg 3.6T 0M 3.6T Y
node3 lvm-vg xenvg 3.6T 2.0G 3.6T Y
Next is repairing storage units, which is currently only implemented for
volume groups and does the equivalent of vgreduce --removemissing:
$ gnt-node repair-storage node2 lvm-vg xenvg
Sun Oct 25 22:21:45 2009 Repairing storage unit 'xenvg' on node2 ...
Last is the modification of volume properties, which is (again) only
implemented for LVM physical volumes and allows toggling the
allocatable value:
$ gnt-node modify-storage --allocatable=no node2 lvm-pv /dev/sdb1
All these commands are needed when recovering a node from a disk
failure:
- first, we need to recover from complete LVM failure (due to missing
disk), by running the repair-storage command
- second, we need to change allocation on any partially-broken disk
(i.e. LVM still sees it, but it has bad blocks) by running
modify-storage
- then we can evacuate the instances as needed
Beside the cluster initialisation command (which is detailed in the
Ganeti installation tutorial document) and the master failover command which is
explained under node handling, there are a couple of other cluster
operations available.
One of the few commands that can be run on any node (not only the
master) is the getmaster command:
# on node2
$ gnt-cluster getmaster
node1.example.com
It is possible to query and change global cluster parameters via the
info and modify commands:
$ gnt-cluster info
Cluster name: cluster.example.com
Cluster UUID: 07805e6f-f0af-4310-95f1-572862ee939c
Creation time: 2009-09-25 05:04:15
Modification time: 2009-10-18 22:11:47
Master node: node1.example.com
Architecture (this node): 64bit (x86_64)
…
Tags: foo
Default hypervisor: xen-pvm
Enabled hypervisors: xen-pvm
Hypervisor parameters:
- xen-pvm:
root_path: /dev/sda1
…
Cluster parameters:
- candidate pool size: 10
…
Default instance parameters:
- default:
memory: 128
…
Default nic parameters:
- default:
link: xen-br0
…
There various parameters above can be changed via the modify
commands as follows:
- the hypervisor parameters can be changed via modify -H
xen-pvm:root_path=…, and so on for other hypervisors/key/values
- the “default instance parameters” are changeable via modify -B
parameter=value… syntax
- the cluster parameters are changeable via separate options to the
modify command (e.g. --candidate-pool-size, etc.)
For detailed option list see the gnt-cluster(8) man page.
The cluster version can be obtained via the version command:
$ gnt-cluster version
Software version: 2.1.0
Internode protocol: 20
Configuration format: 2010000
OS api version: 15
Export interface: 0
This is not very useful except when debugging Ganeti.
There are two commands provided for replicating files to all nodes of a
cluster and for running commands on all the nodes:
$ gnt-cluster copyfile /path/to/file
$ gnt-cluster command ls -l /path/to/file
These are simple wrappers over scp/ssh and more advanced usage can be
obtained using dsh(1) and similar commands. But they are
useful to update an OS script from the master node, for example.
There are three commands that relate to global cluster checks. The first
one is verify which gives an overview on the cluster state,
highlighting any issues. In normal operation, this command should return
no ERROR messages:
$ gnt-cluster verify
Sun Oct 25 23:08:58 2009 * Verifying global settings
Sun Oct 25 23:08:58 2009 * Gathering data (2 nodes)
Sun Oct 25 23:09:00 2009 * Verifying node status
Sun Oct 25 23:09:00 2009 * Verifying instance status
Sun Oct 25 23:09:00 2009 * Verifying orphan volumes
Sun Oct 25 23:09:00 2009 * Verifying remaining instances
Sun Oct 25 23:09:00 2009 * Verifying N+1 Memory redundancy
Sun Oct 25 23:09:00 2009 * Other Notes
Sun Oct 25 23:09:00 2009 - NOTICE: 5 non-redundant instance(s) found.
Sun Oct 25 23:09:00 2009 * Hooks Results
The second command is verify-disks, which checks that the instance’s
disks have the correct status based on the desired instance state
(up/down):
$ gnt-cluster verify-disks
Note that this command will show no output when disks are healthy.
The last command is used to repair any discrepancies in Ganeti’s
recorded disk size and the actual disk size (disk size information is
needed for proper activation and growth of DRBD-based disks):
$ gnt-cluster repair-disk-sizes
Sun Oct 25 23:13:16 2009 - INFO: Disk 0 of instance instance1 has mismatched size, correcting: recorded 512, actual 2048
Sun Oct 25 23:13:17 2009 - WARNING: Invalid result from node node4, ignoring node results
The above shows one instance having wrong disk size, and a node which
returned invalid data, and thus we ignored all primary instances of that
node.
If the verify command complains about file mismatches between the master
and other nodes, due to some node problems or if you manually modified
configuration files, you can force an push of the master configuration
to all other nodes via the redist-conf command:
$ gnt-cluster redist-conf
This command will be silent unless there are problems sending updates to
the other nodes.
It is possible to rename a cluster, or to change its IP address, via the
rename command. If only the IP has changed, you need to pass the
current name and Ganeti will realise its IP has changed:
$ gnt-cluster rename cluster.example.com
This will rename the cluster to 'cluster.example.com'. If
you are connected over the network to the cluster name, the operation
is very dangerous as the IP address will be removed from the node and
the change may not go through. Continue?
y/[n]/?: y
Failure: prerequisites not met for this operation:
Neither the name nor the IP address of the cluster has changed
In the above output, neither value has changed since the cluster
initialisation so the operation is not completed.
The job queue execution in Ganeti 2.0 and higher can be inspected,
suspended and resumed via the queue command:
$ gnt-cluster queue info
The drain flag is unset
$ gnt-cluster queue drain
$ gnt-instance stop instance1
Failed to submit job for instance1: Job queue is drained, refusing job
$ gnt-cluster queue info
The drain flag is set
$ gnt-cluster queue undrain
This is most useful if you have an active cluster and you need to
upgrade the Ganeti software, or simply restart the software on any node:
- suspend the queue via queue drain
- wait until there are no more running jobs via gnt-job list
- restart the master or another node, or upgrade the software
- resume the queue via queue undrain
Note
this command only stores a local flag file, and if you
failover the master, it will not have effect on the new master.
The ganeti-watcher(8) is a program, usually scheduled via
cron, that takes care of cluster maintenance operations (restarting
downed instances, activating down DRBD disks, etc.). However, during
maintenance and troubleshooting, this can get in your way; disabling it
via commenting out the cron job is not so good as this can be
forgotten. Thus there are some commands for automated control of the
watcher: pause, info and continue:
$ gnt-cluster watcher info
The watcher is not paused.
$ gnt-cluster watcher pause 1h
The watcher is paused until Mon Oct 26 00:30:37 2009.
$ gnt-cluster watcher info
The watcher is paused until Mon Oct 26 00:30:37 2009.
$ ganeti-watcher -d
2009-10-25 23:30:47,984: pid=28867 ganeti-watcher:486 DEBUG Pause has been set, exiting
$ gnt-cluster watcher continue
The watcher is no longer paused.
$ ganeti-watcher -d
2009-10-25 23:31:04,789: pid=28976 ganeti-watcher:345 DEBUG Archived 0 jobs, left 0
2009-10-25 23:31:05,884: pid=28976 ganeti-watcher:280 DEBUG Got data from cluster, writing instance status file
2009-10-25 23:31:06,061: pid=28976 ganeti-watcher:150 DEBUG Data didn't change, just touching status file
$ gnt-cluster watcher info
The watcher is not paused.
The exact details of the argument to the pause command are available
in the manpage.
Note
this command only stores a local flag file, and if you
failover the master, it will not have effect on the new master.
If the cluster parameter maintain_node_health is enabled (see the
manpage for gnt-cluster, the init and modify subcommands),
then the following will happen automatically:
- the watcher will shutdown any instances running on offline nodes
- the watcher will deactivate any DRBD devices on offline nodes
In the future, more actions are planned, so only enable this parameter
if the nodes are completely dedicated to Ganeti; otherwise it might be
possible to lose data due to auto-maintenance actions.
The usual method to cleanup a cluster is to run gnt-cluster destroy
however if the Ganeti installation is broken in any way then this will
not run.
It is possible in such a case to cleanup manually most if not all traces
of a cluster installation by following these steps on all of the nodes:
- Shutdown all instances. This depends on the virtualisation method
used (Xen, KVM, etc.):
- Xen: run xm list and xm destroy on all the non-Domain-0
instances
- KVM: kill all the KVM processes
- chroot: kill all processes under the chroot mountpoints
- If using DRBD, shutdown all DRBD minors (which should by at this time
no-longer in use by instances); on each node, run drbdsetup
/dev/drbdN down for each active DRBD minor.
- If using LVM, cleanup the Ganeti volume group; if only Ganeti created
logical volumes (and you are not sharing the volume group with the
OS, for example), then simply running lvremove -f xenvg (replace
‘xenvg’ with your volume group name) should do the required cleanup.
- If using file-based storage, remove recursively all files and
directories under your file-storage directory: rm -rf
/srv/ganeti/file-storage/* replacing the path with the correct path
for your cluster.
- Stop the ganeti daemons (/etc/init.d/ganeti stop) and kill any
that remain alive (pgrep ganeti and pkill ganeti).
- Remove the ganeti state directory (rm -rf /var/lib/ganeti/*),
replacing the path with the correct path for your installation.
- If using RBD, run rbd unmap /dev/rbdN to unmap the RBD disks.
Then remove the RBD disk images used by Ganeti, identified by their
UUIDs (rbd rm uuid.rbd.diskN).
On the master node, remove the cluster from the master-netdev (usually
xen-br0 for bridged mode, otherwise eth0 or similar), by running
ip a del $clusterip/32 dev xen-br0 (use the correct cluster ip and
network device name).
At this point, the machines are ready for a cluster creation; in case
you want to remove Ganeti completely, you need to also undo some of the
SSH changes and log directories:
- rm -rf /var/log/ganeti /srv/ganeti (replace with the correct
paths)
- remove from /root/.ssh the keys that Ganeti added (check the
authorized_keys and id_dsa files)
- regenerate the host’s SSH keys (check the OpenSSH startup scripts)
- uninstall Ganeti
Otherwise, if you plan to re-create the cluster, you can just go ahead
and rerun gnt-cluster init.
Ganeti uses both SSL and SSH keys, and actively modifies the SSH keys on
the nodes. As result, in order to replace these keys, a few extra steps
need to be followed: Cluster Keys Replacement
Starting with Ganeti 2.8, a monitoring daemon is available, providing
information about the status and the performance of the system.
The monitoring daemon runs on every node, listening on TCP port 1815. Each
instance of the daemon provides information related to the node it is running
on.
The queries to the monitoring agent will be HTTP GET requests on port 1815.
The answer will be encoded in JSON format and will depend on the specific
accessed resource.
If a request is sent to a non-existing resource, a 404 error will be returned by
the HTTP server.
The following paragraphs will present the existing resources supported by the
current protocol version, that is version 1.
The root resource. It will return the list of the supported protocol version
numbers.
Currently, this will include only version 1.
Not an actual resource per-se, it is the root of all the resources of protocol
version 1.
If requested through GET, the null JSON value will be returned.
Returns a list of tuples (kind, category, name) showing all the collectors
available in the system.
A list of the reports of all the data collectors, as a JSON list.
Status reporting collectors will provide their output in non-verbose format.
The verbose format can be requested by adding the parameter verbose=1 to the
request.
Returns the report of the collector [collector_name] that belongs to the
specified [category].
The category has to be written in lowercase.
If a collector does not belong to any category, default will have to be
used as the value for [category].
Status reporting collectors will provide their output in non-verbose format.
The verbose format can be requested by adding the parameter verbose=1 to the
request.
The tool harep can be used to automatically fix some problems that are
present in the cluster.
It is mainly meant to be regularly and automatically executed
as a cron job. This is quite evident by considering that, when executed, it does
not immediately fix all the issues of the instances of the cluster, but it
cycles the instances through a series of states, one at every harep
execution. Every state performs a step towards the resolution of the problem.
This process goes on until the instance is brought back to the healthy state,
or the tool realizes that it is not able to fix the instance, and
therefore marks it as in failure state.
By default, harep checks the status of the cluster but it is not allowed to
perform any modification. Modification must be explicitly allowed by an
appropriate use of tags. Tagging can be applied at various levels, and can
enable different kinds of autorepair, as hereafter described.
All the tags that authorize harep to perform modifications follow this
syntax:
ganeti:watcher:autorepair:<type>
where <type> indicates the kind of intervention that can be performed. Every
possible value of <type> includes at least all the authorization of the
previous one, plus its own. The possible values, in increasing order of
severity, are:
- fix-storage allows a disk replacement or another operation that
fixes the instance backend storage without affecting the instance
itself. This can for example recover from a broken drbd secondary, but
risks data loss if something is wrong on the primary but the secondary
was somehow recoverable.
- migrate allows an instance migration. This can recover from a
drained primary, but can cause an instance crash in some cases (bugs).
- failover allows instance reboot on the secondary. This can recover
from an offline primary, but the instance will lose its running state.
- reinstall allows disks to be recreated and an instance to be
reinstalled. This can recover from primary&secondary both being
offline, or from an offline primary in the case of non-redundant
instances. It causes data loss.
These autorepair tags can be applied to a cluster, a nodegroup or an instance,
and will act where they are applied and to everything in the entities sub-tree
(e.g. a tag applied to a nodegroup will apply to all the instances contained in
that nodegroup, but not to the rest of the cluster).
If there are multiple ganeti:watcher:autorepair:<type> tags in an
object (cluster, node group or instance), the least destructive tag
takes precedence. When multiplicity happens across objects, the nearest
tag wins. For example, if in a cluster with two instances, I1 and
I2, I1 has failover, and the cluster itself has both
fix-storage and reinstall, I1 will end up with failover
and I2 with fix-storage.
Sometimes it is useful to stop harep from performing its task temporarily,
and it is useful to be able to do so without distrupting its configuration, that
is, without removing the authorization tags. In order to do this, suspend tags
are provided.
Suspend tags can be added to cluster, nodegroup or instances, and act on the
entire entities sub-tree. No operation will be performed by harep on the
instances protected by a suspend tag. Their syntax is as follows:
ganeti:watcher:autorepair:suspend[:<timestamp>]
If there are multiple suspend tags in an object, the form without timestamp
takes precedence (permanent suspension); or, if all object tags have a
timestamp, the one with the highest timestamp.
Tags with a timestamp will be automatically removed when the time indicated by
the timestamp is passed. Indefinite suspension tags have to be removed manually.
Harep will report about the result of its actions both through its CLI, and by
adding tags to the instances it operated on. Such tags will follow the syntax
hereby described:
ganeti:watcher:autorepair:result:<type>:<id>:<timestamp>:<result>:<jobs>
If this tag is present a repair of type type has been performed on
the instance and has been completed by timestamp. The result is
either success, failure or enoperm, and jobs is a
+-separated list of jobs that were executed for this repair.
An enoperm result is an error state due to permission problems. It
is returned when the repair cannot proceed because it would require to perform
an operation that is not allowed by the ganeti:watcher:autorepair:<type> tag
that is defining the instance autorepair permissions.
NB: if an instance repair ends up in a failure state, it will not be touched
again by harep until it has been manually fixed by the system administrator
and the ganeti:watcher:autorepair:result:failure:* tag has been manually
removed.
The various jobs submitted by the instance/node/cluster commands can be
examined, canceled and archived by various invocations of the
gnt-job command.
First is the job list command:
$ gnt-job list
17771 success INSTANCE_QUERY_DATA
17773 success CLUSTER_VERIFY_DISKS
17775 success CLUSTER_REPAIR_DISK_SIZES
17776 error CLUSTER_RENAME(cluster.example.com)
17780 success CLUSTER_REDIST_CONF
17792 success INSTANCE_REBOOT(instance1.example.com)
More detailed information about a job can be found via the info
command:
$ gnt-job info 17776
Job ID: 17776
Status: error
Received: 2009-10-25 23:18:02.180569
Processing start: 2009-10-25 23:18:02.200335 (delta 0.019766s)
Processing end: 2009-10-25 23:18:02.279743 (delta 0.079408s)
Total processing time: 0.099174 seconds
Opcodes:
OP_CLUSTER_RENAME
Status: error
Processing start: 2009-10-25 23:18:02.200335
Processing end: 2009-10-25 23:18:02.252282
Input fields:
name: cluster.example.com
Result:
OpPrereqError
[Neither the name nor the IP address of the cluster has changed]
Execution log:
During the execution of a job, it’s possible to follow the output of a
job, similar to the log that one get from the gnt- commands, via the
watch command:
$ gnt-instance add --submit … instance1
JobID: 17818
$ gnt-job watch 17818
Output from job 17818 follows
-----------------------------
Mon Oct 26 00:22:48 2009 - INFO: Selected nodes for instance instance1 via iallocator dumb: node1, node2
Mon Oct 26 00:22:49 2009 * creating instance disks...
Mon Oct 26 00:22:52 2009 adding instance instance1 to cluster config
Mon Oct 26 00:22:52 2009 - INFO: Waiting for instance instance1 to sync disks.
…
Mon Oct 26 00:23:03 2009 creating os for instance instance1 on node node1
Mon Oct 26 00:23:03 2009 * running the instance OS create scripts...
Mon Oct 26 00:23:13 2009 * starting instance...
$
This is useful if you need to follow a job’s progress from multiple
terminals.
A job that has not yet started to run can be canceled:
But not one that has already started execution:
$ gnt-job cancel 17805
Job 17805 is no longer waiting in the queue
There are two queues for jobs: the current and the archive
queue. Jobs are initially submitted to the current queue, and they stay
in that queue until they have finished execution (either successfully or
not). At that point, they can be moved into the archive queue using e.g.
gnt-job autoarchive all. The ganeti-watcher script will do this
automatically 6 hours after a job is finished. The ganeti-cleaner
script will then remove archived the jobs from the archive directory
after three weeks.
Note that gnt-job list only shows jobs in the current queue.
Archived jobs can be viewed using gnt-job info <id>.
Since Ganeti 2.4, it is possible to extend the Ganeti deployment with
two custom scenarios: Ganeti inside Ganeti and multi-site model.
It is sometimes useful to be able to use a Ganeti instance as a Ganeti
node (part of another cluster, usually). One example scenario is two
small clusters, where we want to have an additional master candidate
that holds the cluster configuration and can be used for helping with
the master voting process.
However, these Ganeti instance should not host instances themselves, and
should not be considered in the normal capacity planning, evacuation
strategies, etc. In order to accomplish this, mark these nodes as
non-vm_capable:
$ gnt-node modify --vm-capable=no node3
The vm_capable status can be listed as usual via gnt-node list:
$ gnt-node list -oname,vm_capable
Node VMCapable
node1 Y
node2 Y
node3 N
When this flag is set, the cluster will not do any operations that
relate to instances on such nodes, e.g. hypervisor operations,
disk-related operations, etc. Basically they will just keep the ssconf
files, and if master candidates the full configuration.
If Ganeti is deployed in multi-site model, with each site being a node
group (so that instances are not relocated across the WAN by mistake),
it is conceivable that either the WAN latency is high or that some sites
have a lower reliability than others. In this case, it doesn’t make
sense to replicate the job information across all sites (or even outside
of a “central” node group), so it should be possible to restrict which
nodes can become master candidates via the auto-promotion algorithm.
Ganeti 2.4 introduces for this purpose a new master_capable flag,
which (when unset) prevents nodes from being marked as master
candidates, either manually or automatically.
As usual, the node modify operation can change this flag:
$ gnt-node modify --auto-promote --master-capable=no node3
Fri Jan 7 06:23:07 2011 - INFO: Demoting from master candidate
Fri Jan 7 06:23:08 2011 - INFO: Promoted nodes to master candidate role: node4
Modified node node3
- master_capable -> False
- master_candidate -> False
And the node list operation will list this flag:
$ gnt-node list -oname,master_capable node1 node2 node3
Node MasterCapable
node1 Y
node2 Y
node3 N
Note that marking a node both not vm_capable and not
master_capable makes the node practically unusable from Ganeti’s
point of view. Hence these two flags should be used probably in
contrast: some nodes will be only master candidates (master_capable but
not vm_capable), and other nodes will only hold instances (vm_capable
but not master_capable).
Beside the usual gnt- and ganeti- commands which are provided
and installed in $prefix/sbin at install time, there are a couple of
other tools installed which are used seldom but can be helpful in some
cases.
The lvmstrap tool, introduced in Configuring LVM section,
has two modes of operation:
- diskinfo shows the discovered disks on the system and their status
- create takes all not-in-use disks and creates a volume group out
of them
Warning
The create argument to this command causes data-loss!
The cfgupgrade tools is used to upgrade between major (and minor)
Ganeti versions, and to roll back. Point-releases are usually
transparent for the admin.
More information about the upgrade procedure is listed on the wiki at
http://code.google.com/p/ganeti/wiki/UpgradeNotes.
There is also a script designed to upgrade from Ganeti 1.2 to 2.0,
called cfgupgrade12.
Note
This command is not actively maintained; make sure you backup
your configuration before using it
This can be used as an alternative to direct editing of the
main configuration file if Ganeti has a bug and prevents you, for
example, from removing an instance or a node from the configuration
file.
Warning
This command will erase existing instances if given as
arguments!
This tool is used to exercise either the hardware of machines or
alternatively the Ganeti software. It is safe to run on an existing
cluster as long as you don’t pass it existing instance names.
The command will, by default, execute a comprehensive set of operations
against a list of instances, these being:
- creation
- disk replacement (for redundant instances)
- failover and migration (for redundant instances)
- move (for non-redundant instances)
- disk growth
- add disks, remove disk
- add NICs, remove NICs
- export and then import
- rename
- reboot
- shutdown/startup
- and finally removal of the test instances
Executing all these operations will test that the hardware performs
well: the creation, disk replace, disk add and disk growth will exercise
the storage and network; the migrate command will test the memory of the
systems. Depending on the passed options, it can also test that the
instance OS definitions are executing properly the rename, import and
export operations.
This tool takes the Ganeti configuration and outputs a “sanitized”
version, by randomizing or clearing:
- DRBD secrets and cluster public key (always)
- host names (optional)
- IPs (optional)
- OS names (optional)
- LV names (optional, only useful for very old clusters which still have
instances whose LVs are based on the instance name)
By default, all optional items are activated except the LV name
randomization. When passing --no-randomization, which disables the
optional items (i.e. just the DRBD secrets and cluster public keys are
randomized), the resulting file can be used as a safety copy of the
cluster config - while not trivial, the layout of the cluster can be
recreated from it and if the instance disks have not been lost it
permits recovery from the loss of all master candidates.
Ganeti can either be run entirely as root, or with every daemon running as
its own specific user (if the parameters --with-user-prefix and/or
--with-group-prefix have been specified at ./configure-time).
In case split users are activated, they are required to exist on the system,
and they need to belong to the proper groups in order for the access
permissions to files and programs to be correct.
The users-setup tool, when run, takes care of setting up the proper
users and groups.
When invoked without parameters, the tool runs in interactive mode, showing the
list of actions it will perform and asking for confirmation before proceeding.
Providing the --yes-do-it parameter to the tool prevents the confirmation
from being asked, and the users and groups will be created immediately.
Below is a list (which might not be up-to-date) of additional projects
that can be useful in a Ganeti deployment. They can be downloaded from
the project site (http://code.google.com/p/ganeti/) and the repositories
are also on the project git site (http://git.ganeti.org).


This module is only useful if the module DNN-DeleteUnauthorisedUsers has been installed by the host user.
The Edit Portal Settings module is designed to add portal settings to be used by a scheduled task. The Shedule Task is designed to optionally delete unauthorised users after a specified time period since registration. It is an attempt to help administrators in the fight against "spam user registrations". The idea is that the spam users tend to have invalid email addresses and, as a result, never verify their registration and thus do not become authorised. Genuine user registrations will tend to verify their account in the same session.
Four settings are used for each portal:
This is a true/false value indicating if users should be deleted when the scheduled taks runs.
This is a numeric valus indicating the number of minutes to elapse before a user will be deleted id AutoDeleteUsers is set to true.
A deleted user may be restored in DNN by following Users > Manage Users and selecting Deleted to list deleted users. Individual deleted users may be restored. If AutoPurgeUsers is set to true then deleted users can only be restored before they are removed from the database.
This is a true/false value indicating if users should be removed from the database when the scheduled taks runs.
This is a numeric valus indicating the number of days to elapse before a user will be removed from the database if AutoPurgeUsers is set to true. Once users are removed from the database they cannot be restored.
The module will take into account the access level of the logged in user. Only administrators or host users can use this module.
Administrators will only see the portal settings for their own portal (website). A host user will see the portal settings for all portals sorted by portal ID.
The Schedule Task is a separate module.


Abmas, Burns send Oral Roberts past SW Christian by 54 PTs
TULSA, Okla. (AP) - Deondre Burns registered 17 points as Oral Roberts beat NAIA-member Southwestern Christian 99-45 on Monday night.
Max Abmas had 18 points for Oral Roberts (3-4). Aidan Saunders added 13 points. Ty Lazenby had 12 points and six rebounds for the home team.
Charles Dickson had 11 points and six rebounds for the Eagles. Richard Anderson added 11 points and six rebounds.
Oral Roberts plays Creighton on the road next Tuesday.
For more AP college basketball coverage: https://apnews.com/Collegebasketball and http://twitter.com/AP_Top25
This was generated by Automated Insights, http://www.automatedinsights.com/ap, using data from STATS LLC, https://www.stats.com
Sign up for Daily Newsletters
Copyright © 2019 The Washington Times, LLC.
Please read our comment policy before commenting.


We're in the home stretch!
There are two weeks left in the term. You should be done with your book, or at least close. It's time to start reflecting.
Once you've finished your book, submit a reflection here. Don't put it off any longer -- this doesn't have to take a long time. Reflection is an important part of your continued growth.
I'm looking forward to reading what you have to say! We have a lot to learn together.
Best,
Greg, under the guise of Every6.


Directions:
Go to
my.stevens.edu
Click Student/Faculty Web Self Services
Click Student & Financial Aid
Go to Student Records -> Unofficial Transcript
Click the button to see your study plan
For any issues, contact dheyman@stevens.edu


Isaac Newton
Scientist, Mathematician, Biblical Commentor, Professor,...
A timeline of Sir Isaac Newton's life:
-
1642, age 0
- Born December 25, 1642 (old calendar) in Woolsthorpe, a small village in Lincolnshire, England. Two months prior, his father Isaac Newton died."
- In today’s Gregorian calendar, Isaac was born January 4th, 1643.
-
1645, age 2
- His mother Hannah Ayscough married Barnabas Smith, of 63 years of age, the minister of the church at North Witham. Isaac was left in the care of his maternal grandparents.
-
1645-1653, ages 2-10
- The period in which Isaac was under the care of his maternal grandparents. Isaac learned to read and write from his material grandmother and mother.
-
1653, age 10
- Barnabas Smith passes away. Isaac’s mother, Hannah, returned to Woolshtorpe with the three children she had with Smith.
-
1655, age 12
- Attends the King's boarding school in Grantham
-
1659, age 16
- Returns hoem to manage the family farm full time; a task he is not very sucessful with
-
1659-1661, ages 16-18
- Hannah’s brother, the headmaster of the Grantham school, persuades her that Isaac should prepare to enroll into a university. Isaac receives further schooling at Grantham.
-
1661, age 18
- Matriculates at Trinity College, Cambridge.
- Funds his studies by taking on the job of a sizar (acting as a servant for social superior classmates or for tutors)
-
1662, age 19
- Draws up a list of 48 sins he committed before and then after Pentecost of this year.
- E.g., “Using the word (God) openly”, “Threatning my father and mother Smith to burne them and the house over them”, “Wishing death and hoping it to some”, “Punching my sister”, “Fearing man above Thee”, “Using unlawful means to bring us out of distresses”, etc.
-
1661-1665, ages 18-22
- Isaac’s education covered the classics on Aristotelian rhetoric, logic, ethics, and physics. Isaac later begun to teach himself mathematics by studying the works by Oughtred, Viete, Wallis, and Descartes.
-
1663, age 20
- Becomes friends with John Wickins and then onward are roommates for the next twenty years.
-
1665, age 22
- Received his bachelor’s degree in April 1665.
- A small scale of the bubonic plague strikes England. In the summer, Isaac returns home to Woolsthorpe.
-
1665-1666, ages 22-23
- Isaac makes his initial experimental discoveries in optics and independently developed the mathematical theory of uniform circular motion. He sets down the basic rules of differentiation and integration in a paper of October 1666. This later becomes the fundamentals of what is now called calculus.
-
1667, age 24
- Elected to a fellowship in Trinity College after the university had been closed due to the plague.
- Continues his research in optics.
- Extends his tract on calculus by incorporating new work on infinite series.
-
1669, age 26
- Replaces Isaac Barrow as Lucasian Professor of Mathematics at Trinity upon Barrow’s recommendation.
- Begins a more private research in the subjects of alchemy and theology.
-
1671, age 28
- Completes most of a treatise length account of calculus. Unfortunately, Isaac found no willing publisher to take on calculus during this time.
-
1672, age 29
- Submits his works in optics to the Royal Society and published in the Philosophical Transcation of the Royall Society journal.
-
1672-1676, ages 29-33
- Isaac’s work in optics is challenged by figures like Robert Hooke and Christiaan Huygens.
-
1679, age 36
- Returns to Woolshorpe to care for his dying mother who later dies on April 14th.
-
1684-1687, ages 41-44
- Extends his work on “De Motu Corporum in Gyrum” (“On the Motion of Bodies in Orbit”) becoming the 500 page, Principia.
- Theory of universal gravitation: every object in the universe attracts and is attracted to every other object.
-
1689-1690?, ages 46-47
- During this period, Isaac represented Cambridge University in the Convention Parliament.
- Befriends John Locke and Nicolas Fatio de Duillier.
- Meets Christiaan Huygens in person.
- Writes his principal treatise in alchemy, Praxis
- Corresponds with Richard Bentley on religion.
- Exchanges with John Locke discussing passages in the Bible on the Trinity.
-
1696, age 53
- Accepts the position of Warden of the Mint in the city of London
-
1699, age 56
- Becomes Master of the Mint in the city of London
-
1701, age 58
- Represents Cambridge University in Parliament for 16 months
- Resigns his Fellowship and Lucasian Professorship from Trinity College
-
1702, age 59
- Designs Queen Anne’s Coronation Medal
-
1703, age 61
- Elected President of the Royal Society
-
1704, age 62
- The first English edition of Isaac’s Opticks is printed
-
1705, age 63
- Knighted Sir Isaac Newton by Queen Anne. This marked the first time which a scientist was given such an honor.
-
1706, age 64
- A latin edition of Opticks is printed
-
1709, age 67
- Begins work towards a second edition of Principia
-
1713, age 71
- A second edition of Principia is printed. Adds a ‘General Scholium’ setting out Newton’s view of the relationship between God and Creation
-
1716, age 73
- Compiles his theories on ancient chronology at the request of Princess Caroline of Wales. Newton asks her to keep the manuscript to herself which she does not. A Short Chronicle from the First Memory of Things in Europe, to the Conquest of Persia by Alexander the Great
-
1717, age 74
- A second English edition of Opticks is printed
-
1721, age 78
- A third English edition of Opticks is printed
-
1722, age 79
- Begins to suffer from bladder stones
-
1723, age 80
- Begins work towards a third edition of Principia
-
1726, age 83
- A third edition of Principia is printed
-
1727, age 84
- Attends his last Royal Society meeting on February 19. Suffers from a new bladder stone that night.
- Dies on March 20, 1727 having refused the last rites.
Learn more by checking out the reference links below
NewtonProject.ox.au.ukPlato.Standford.edu
Britannica.com


5 Reasons To Choose A
Notebook Over A Computer
Desktop
Get Around Easily With A New
York Limousine Service
How To Cook A Tender Juicy Steak
How To Remove Kidney Stones
The Science Of Superstitions
5 Reasons To Choose a Notebook Over A Computer Desktop
Get Around Easily With A New York Limousine Service
How To Cook A Tender Juicy Steak
How To Remove Kidney Stones
The Science Of Superstitions
Gordon Carroll
Adeline Wilkins
John Wheeler
Katherine Nelson
Calm Videos - Rain
125,000 Vistas
Relaxing sound of waterfall in South America
Relaxing sound of countryside in North America
Comentarios
Gordon Carroll
It's very relaxing
Adeline Wilkins
I love the sound of the rain
John Wheeler
The best sounds are the sounds of the nature
Adeline Wilkins
I love the sound of the rain
Gordon Carroll
It's very relaxing


[gecode-users] gecode 1.0.0 fails to build with gcc 4.2 snapshot
Guido Tack
tack at ps.uni-sb.de
Sun Apr 9 00:16:22 CEST 2006
Hi!
> Martin Michlmayr tried to build gecode 1.0.0 with gcc 4.2 snapshot,
> unsuccessully. Is this something that would concern 1.0.1 or the
> upcoming 1.1.0(?)?
I'm sorry, we currently don't have a gcc 4.2 accessible anywhere, so I
can't make any promises. However, Gecode 1.1.0 (to be released anytime
soon now) builds successfully with gcc 4.1.0, just as Martin reports.
I've had a look at the debian bug report. It really looks odd. The
compiler suggests to use -fPIC, although that's in fact switched on by
default. So, at the moment, I'd guess it's a problem in gcc 4.2 rather
than in Gecode.
As said, Gecode 1.1.0 is due next week. If you have any suggestions how we
could make your life easier concerning packaging, please let us know!
Cheers,
Guido
--
Guido Tack
http://www.ps.uni-sb.de/~tack
More information about the gecode-users
mailing list


DUE - Extensions
Extensions are user defined functions that reside in the environment until called, they are just like any other functions in the script however these functions are provided from the TinyCLR C# side.
Defining Extensions
A static class is used to implement the extensions. Each static method in this class become available to scripts.
static class ExtensionLibrary {
public static void ExtensionFuncSample(string arg) {
Debug.WriteLine("Arg: " + arg);
}
public static int ExtensionAdder(int arg1, int arg2) {
return arg1 + arg2;
}
}
Constants (const in DUE) can also be made available to the DUE system using readonly
C# keyword.
static class ExtensionLibrary {
public static void TestSample(int arg) {
Debug.WriteLine("Arg: " + arg);
}
public readonly int PE11 = 75;
Any members of the extension that should not be accessed from within DUE scripts should not be made public
.
Tip
Variable binding is not supported and should not be used, only use variables that are readonly
.
Acessing Extensions
The DUE ScriptEngine
does all the necessary magic internally. The user only needs to provide the extension class.
var script = new ScriptEngine(typeof(ExtensionLibrary));
script.Run(@"ExtensionFuncSample(""Hello DUE!"")
var x = ExtensionAdder(44, 77)
ExtensionFuncSample(""x: "" + x)
");
Similar to any other functions in DUE, extensions can also be invoked from the engine directly engine.Invoke("ExtensionFuncSample","Hello DUE!")
.
Example
// Non-public functions and member variables are not loaded into the script engine
static class GpioExtension {
private static Hashtable pins = new Hashtable();
private static GpioController gpio = GpioController.GetDefault();
// Public static redonly member variables will be exposed as constants in the engine
public static readonly int On = 1;
public static readonly int Off = 0;
// DigitalPin - Return a Pin object for the specified pin
public static object DigitalPin(int pinNumber) {
if (!pins.Contains(pinNumber)) {
pins[pinNumber] = gpio.OpenPin(pinNumber);
}
return pins[pinNumber];
}
// WritePin - Write the state to the pin
public static void WritePin(object pin, int state) {
if (pin is GpioPin gpioPin) {
gpioPin.SetDriveMode(GpioPinDriveMode.Output);
gpioPin.Write(state == 0 ? GpioPinValue.Low : GpioPinValue.High);
}
else {
throw new InterpreterException("Not a valid pin");
}
}
// ReadPin - Read the current state of the pin
public static int ReadPin(object pin) {
if (pin is GpioPin gpioPin) {
gpioPin.SetDriveMode(GpioPinDriveMode.Input);
return gpioPin.Read() == GpioPinValue.High ? 1 : 0;
}
else {
throw new InterpreterException("Not a valid pin");
}
}
}


QDesignerCustomWidgetInterface Class
The QDesignerCustomWidgetInterface class enables Qt Designer to access and construct custom widgets. More...
| Header: | #include <QDesignerCustomWidgetInterface> |
| qmake: | QT += designer |
Public Functions
| virtual | ~QDesignerCustomWidgetInterface() |
| virtual QString | codeTemplate() const |
| virtual QWidget * | createWidget(QWidget *parent) = 0 |
| virtual QString | domXml() const |
| virtual QString | group() const = 0 |
| virtual QIcon | icon() const = 0 |
| virtual QString | includeFile() const = 0 |
| virtual void | initialize(QDesignerFormEditorInterface *formEditor) |
| virtual bool | isContainer() const = 0 |
| virtual bool | isInitialized() const |
| virtual QString | name() const = 0 |
| virtual QString | toolTip() const = 0 |
| virtual QString | whatsThis() const = 0 |
Macros
Detailed Description
The QDesignerCustomWidgetInterface class enables Qt Designer to access and construct custom widgets.
QDesignerCustomWidgetInterface provides a custom widget with an interface. The class contains a set of functions that must be subclassed to return basic information about the widget, such as its class name and the name of its header file. Other functions must be implemented to initialize the plugin when it is loaded, and to construct instances of the custom widget for Qt Designer to use.
When implementing a custom widget you must subclass QDesignerCustomWidgetInterface to expose your widget to Qt Designer. For example, this is the declaration for the plugin used in the Custom Widget Plugin example that enables an analog clock custom widget to be used by Qt Designer:
class AnalogClockPlugin : public QObject, public QDesignerCustomWidgetInterface { Q_OBJECT Q_PLUGIN_METADATA(IID "org.qt-project.Qt.QDesignerCustomWidgetInterface") Q_INTERFACES(QDesignerCustomWidgetInterface) public: explicit AnalogClockPlugin(QObject *parent = 0); bool isContainer() const override; bool isInitialized() const override; QIcon icon() const override; QString domXml() const override; QString group() const override; QString includeFile() const override; QString name() const override; QString toolTip() const override; QString whatsThis() const override; QWidget *createWidget(QWidget *parent) override; void initialize(QDesignerFormEditorInterface *core) override; private: bool initialized; };
Note that the only part of the class definition that is specific to this particular custom widget is the class name. In addition, since we are implementing an interface, we must ensure that it's made known to the meta object system using the Q_INTERFACES() macro. This enables Qt Designer to use the qobject_cast() function to query for supported interfaces using nothing but a QObject pointer.
After Qt Designer loads a custom widget plugin, it calls the interface's initialize() function to enable it to set up any resources that it may need. This function is called with a QDesignerFormEditorInterface parameter that provides the plugin with a gateway to all of Qt Designer's API.
Qt Designer constructs instances of the custom widget by calling the plugin's createWidget() function with a suitable parent widget. Plugins must construct and return an instance of a custom widget with the specified parent widget.
Exporting your custom widget plugin to Qt Designer using the Q_PLUGIN_METADATA() macro. For example, if a library called libcustomwidgetplugin.so
(on Unix) or libcustomwidget.dll
(on Windows) contains a widget class called MyCustomWidget
, we can export it by adding the following line to the file containing the plugin header:
Q_PLUGIN_METADATA(IID "org.qt-project.Qt.QDesignerCustomWidgetInterface")
This macro ensures that Qt Designer can access and construct the custom widget. Without this macro, there is no way for Qt Designer to use it.
When implementing a custom widget plugin, you build it as a separate library. If you want to include several custom widget plugins in the same library, you must in addition subclass QDesignerCustomWidgetCollectionInterface.
Warning: If your custom widget plugin contains QVariant properties, be aware that only the following types are supported:
- QVariant::ByteArray
- QVariant::Bool
- QVariant::Color
- QVariant::Cursor
- QVariant::Date
- QVariant::DateTime
- QVariant::Double
- QVariant::Int
- QVariant::Point
- QVariant::Rect
- QVariant::Size
- QVariant::SizePolicy
- QVariant::String
- QVariant::Time
- QVariant::UInt
For a complete example using the QDesignerCustomWidgetInterface class, see the Custom Widget Example. The example shows how to create a custom widget plugin for Qt Designer.
See also QDesignerCustomWidgetCollectionInterface and Creating Custom Widgets for Qt Designer.
Member Function Documentation
[virtual]
QDesignerCustomWidgetInterface::~QDesignerCustomWidgetInterface()
Destroys the custom widget interface.
[virtual]
QString QDesignerCustomWidgetInterface::codeTemplate() const
This function is reserved for future use by Qt Designer.
[pure virtual]
QWidget *QDesignerCustomWidgetInterface::createWidget(QWidget *parent)
Returns a new instance of the custom widget, with the given parent.
[virtual]
QString QDesignerCustomWidgetInterface::domXml() const
Returns the XML that is used to describe the custom widget's properties to Qt Designer.
[pure virtual]
QString QDesignerCustomWidgetInterface::group() const
Returns the name of the group to which the custom widget belongs.
[pure virtual]
QIcon QDesignerCustomWidgetInterface::icon() const
Returns the icon used to represent the custom widget in Qt Designer's widget box.
[pure virtual]
QString QDesignerCustomWidgetInterface::includeFile() const
Returns the path to the include file that uic uses when creating code for the custom widget.
[virtual]
void QDesignerCustomWidgetInterface::initialize(QDesignerFormEditorInterface *formEditor)
Initializes the widget for use with the specified formEditor interface.
See also isInitialized().
[pure virtual]
bool QDesignerCustomWidgetInterface::isContainer() const
Returns true if the custom widget is intended to be used as a container; otherwise returns false.
Most custom widgets are not used to hold other widgets, so their implementations of this function will return false, but custom containers will return true to ensure that they behave correctly in Qt Designer.
[virtual]
bool QDesignerCustomWidgetInterface::isInitialized() const
Returns true if the widget has been initialized; otherwise returns false.
See also initialize().
[pure virtual]
QString QDesignerCustomWidgetInterface::name() const
Returns the class name of the custom widget supplied by the interface.
The name returned must be identical to the class name used for the custom widget.
[pure virtual]
QString QDesignerCustomWidgetInterface::toolTip() const
Returns a short description of the widget that can be used by Qt Designer in a tool tip.
[pure virtual]
QString QDesignerCustomWidgetInterface::whatsThis() const
Returns a description of the widget that can be used by Qt Designer in "What's This?" help for the widget.
Macro Documentation
QDESIGNER_WIDGET_EXPORT
This macro is used when defining custom widgets to ensure that they are correctly exported from plugins for use with Qt Designer.
On some platforms, the symbols required by Qt Designer to create new widgets are removed from plugins by the build system, making them unusable. Using this macro ensures that the symbols are retained on those platforms, and has no side effects on other platforms.
For example, the World Time Clock Plugin example exports a custom widget class with the following declaration:
class QDESIGNER_WIDGET_EXPORT WorldTimeClock : public QWidget { Q_OBJECT ... };
This function was introduced in Qt 4.1.
See also Creating Custom Widgets for Qt Designer.


Gatekeeper Flauen:
This place - my home - has been untouched by the passage of time. But now, the winds of change have begun to blow ... even here amidst the beauty of Heine.
While change often brings with it uncertainty and even anxiety, I sense something indescribable on the wind. Something ominous. Something perhaps even deadly.
I hope these feelings of mine are wrong.
"I hope so too."


The Jurism reference management system is an effort to provide the benefits of modern reference management technology to lawyers and multilingual scholars. None of the project’s tools or websites impose advertising on the user, user data is not shared with third parties, and where information is collected, it is deleted after serving its purpose. See below for specifics on information collected, and the purpose of collection.
Special Note on Cookies
Cookies are of particular concern to privacy-conscious users, so a special note on the way they are handled by the Jurism connectors is in order. Websites visited by the browser often set cookies for various purposes of their own, including the imposition of paywalls and other content restrictions. The Jurism Connector plugins have no control over these uses of cookies. However, in order to extract bibliographic information from pages visited in the browser, the Jurism Connectors must make an accessible and fully rendered image of the page internally. In order to to this, cookies associated with the page are replicated, together to other featurs of the page. This access to cookie data is done for that limited purpose only, the copied data is ephemeral, does not leave the user’s computer, and is not copied or otherwise shared with third parties.
System Elements
The system consists of six elements:
- a library client installed on the user’s computer;
- a distribution server that supplies automatic updates to the library client.
- a debugging service to which users may voluntarily submit logs of the internal operation of the library client for examination by the Jurism developers;
- connectors that enable web browsers to save bibliographic details from web pages to the library client;
- integration plugins that support one-click insertion of references into word processor documents;
- Zotero storage, an optional third-party service to which users may syncronize the content of the library client.
The collection and disposition of information in each of these elements is as follows:
Library Client
The library client itself is a standalone tool installed on the user’s computer that is as secure to outside access as the computer’s operating system.
Distribution Server
The library client is updated from time to time with bugfixes and new features. Unless disabled by the user, these updates operate by the library client polling a distribution server once per day, and installing updates when a fresh update is detected. These polling transactions are logged on the distributon server with their originating IP address. This information may be used to identify the number of unique installations of the library client exist in the field. IP addresses and other details contained in the log files are not and will not be shared with third parties, and the information is deleted after one month.
Debugging Service
For debugging purposes, the Jurism maintainers may invite a user to submit a “Debugging Report” logging the internal state of the library client during a problematic operation. These records contain no identifying information of the individual user, are not shared with third parties, and are deleted after two weeks.
Connectors
The browser connectors pass information on two channels. First, they rely on the library client to provide “translator” code to extract bibliographic information from web pages, and in return send bibliographic records to the library client for storage. These transactions take place within the user’s computer. Second, the connectors support word processor integration with the Google Docs service, which has a separate Privacy Policy.
Integration Plugins
The word processor integration plugins communicate with the library client to support one-click insertion of references in user documents. These transactions take place inside the user’s computer, and do not involve collection of data of any kind.
Zotero Storage
The cloud sync service Zotero Storage is maintained by the unaffiliated upstream parent of the Jurism project. The Zotero privacy policy is available at: https://www.zotero.org/support/privacy.


COINABLES.GITHUB.IO
Welcome to my Open Source and fund raising page!
Please support my work and future works: 3DevXQGCEk7934Ac7P1pPbBAc3Ay2uDueA ⚄[qrcode]
This site is a collection of some open source client-side bitcoin web apps I have built.
Feel free to fork any of these projects.
- Orion.Ninja - Bitcoin transaction visualizer.
- SegwitAddress.org - Segwit paper wallet app.
- FastWallet - A serverless HD bitcoin web wallet I built for casual/throwaway use cases.
- Explorer - Simple bitcoin block explorer.
- BIP39 Generator - BIP39 mnemonic phrase generator that uses your mouse movements plus some CSPRNG for entropy.
- MultiSig Paper Wallet - Multisig tool with Transaction Builder and Offline Key Signer.
- Drag-Drop - Create private keys by drag and dropping a file or image.
- Cold Signer - Tool to build and sign transactions offline.
- Breev - A simple clone of the infamous bitcoin conversion site, preev.com
- Buidljs - A playground for buidljs.
- Mnemonic Recovery - A tool to brute force one missing word from a 12-word menmonic phrase.
Other Works:
- Wrote API Tutorial Articles in 2015 for Blockchain.info blog.
- Developed & Launched one of the first Lightning Explorers in 2018, recognized by Jameson Lopp (https://twitter.com/lopp/status/963440343063543808?s=20)
- Published over 100 bitcoin programming tutorials on my YT channel (https://www.youtube.com/@coinables/videos)
- Contributor to Bitcoin Core v0.15
Warning!
Although this site does not save, store, or log any private keys, it is very important not to re-use a private key of an address entered on any website including this site. Whenever entering a private key into any online form you should assume that address is no longer safe.
Use At Your Own Risk:
Every app on this page is for educational purposes only. There are no guarantees.


The Cumberland River Baisn includes 18,000 square miles of land and 20,000 miles of streams and rivers. This region is one of the most biodiverse on Earth — home to thousands of plant and animal species and nearly 3 million people.
Here you can find your waterway by street address, determine its health, and get connected to people, ideas, and resources for improving the water quality in your community.


Gary Neville defends Glazer family after criticism from Man Utd fans
Gary Neville admits he will never protest against the Glazer family and their ownership of Manchester United.
The Glazers took control of United as part of a £790 million takeover in 2005 but the club have been saddled with a huge debt ever since.
United supporters are now urging the Glazer family to sell following the club’s decline during their reign.
But Neville believes that new owners could provide even more problems for United.
‘Are they the worst owners in football? No. Are they the best? No,’ Neville said in an interview with The Times.
‘My biggest problem with the Glazer family over the past seven years is the campaign 2004-06 where Manchester United weren’t successful, Arsene Wenger came in with the Invincibles [Arsenal], Jose [Mourinho] came in [at Chelsea], that’s when there was a real hostility.
Advertisement Advertisement
‘All of a sudden in 2006 to 2012, where we were getting to three in four Champions League finals, and winning trophies, it went quiet.
‘Then in 2014-15 when we started to get into a period of non-success again, it builds up again.
‘The idea of screaming about the Glazers every ten minutes, saying they are not good owners, doesn’t get us anywhere.
‘I’d love owners that pump every penny back into the club on to the pitch, that didn’t take out £20 million a year, or whatever they take out in debt against the club.
‘But I can’t do anything about it. Just stand there and campaign and whinge? Stand on the front of Old Trafford in front of Best, Law and Charlton with my placard up saying ‘Glazers out?’
‘I’m not going to do that because I haven’t got the solution.’


Organization: {{project.OrganizationName}}
Project: {{project.Name}}
Date: {{project.DateCreated | date :"shortDate"}}


The Handcraft Store
Handcraft gifts for special ocasions!
Home
Prices
Products Gallery
Boxes
Cards
Scrapbooks
Customized
Templates
Gallery
Candles
About us
Videos
Home
Scrapbooks
Our Boxes
Our Candles
Our Cards
Under construction - Content will be available soon!


MATCHING UP IDEAS AND SKILLS
Username:
Password:
First Name:
Last Name:
Gender:
Email:
School:
Major:
{% for line in availableSchools %}
{{line.school_name}} - {{line.major}}
{% endfor %}
{% if error %}
Error:
{{error}}
{% endif %}
Go back


plist - All-purpose Property List manipulation library
Release version 3.0.0!
2010-02-23:
* Ruby 1.9.x compatibility!
2010-02-16:
* excise a bunch of unnecessary @@ variables * fix up some tests for cross-version compatibility
2010-02-14:
* generalized cleanup: * fix old file headers * modernize rakefile * clean up rdoc
2010-01-08:
* move from RubyForge Subversion to GitHub
2007-02-22 (r81):
* make the plist parser accept strings contain XML or any object that responds to #read (File and StringIO being the intended targets here). Test and idea contributed by Chuck Remes.
2006-09-20 (r80):
* tweak a comment in generator.rb to make it clear that we're not using Base64.b64encode because it's broken.
Release version 3.0.0!
2006-09-20 (r77 - r79):
* move IndentedString inside Plist::Emit and :nodoc: it * Tag 3.0.0! (from rev 78)
2006-09-19 (r73 - r75):
* Really fix the rakefile this time (apparently I deleted some code that I needed...) * alter the fix_whitespace rake task to ignore the assets directory * cleanup whitespace
2006-09-18 (r70 - r72):
* Update this file ;) * Fix Rakefile * gem install -t now works correctly * Remove super-sekr1t rdoc staging area from rdoc publishing task
2006-09-15 (r64 - r69):
- Change behavior of empty collection elements to match What Apple Does
- Fix some gem packaging infrastructure
2006-09-13 (r61 - r63):
- Merge generator injection removal branch into trunk!
2006-09-13 (r52 - r60):
- Fix indentation/newlines in generator (finally!)
- Refix indentation to be more faithful to the way Apple emits their plists
- Remove horrific regex and replace it with proper comment parsing
- Empty plists return nil when parsed
- Sort hash keys before emitting (now we can test multi-element hashes!)
- Inject #<=> into Symbol so that sorting Symbol-keyed hashes won’t freak out
2006-09-12 (r47 - r51):
- More test rejiggering
- New tests to expose some bugs
2006-09-10 (r33 - r46):
- Update tests for new generator code
- Rejigger some tests
- Make the generator try to call to_plist_node on any object it tries to serialize, thus allowing class authors to define how their objects will be serialized
- Marshal.dump unrecognized objects into elements
- Make the parser strip out comments and Marshal.load elements if possible
- Update some rdoc
Release version 2.1.1!
2006-09-10 (r31 - r32):
- Added encoding / decoding for entities (& etc)
- Changed parsing of elements to return StringIO objects
- Fixed bug with empty
tags
2006-08-24 (r25 - r30):
- Invert ownership of methods in the generator, allowing us to remove the self.extend(self)
- New branch to remove method inject from parser
2006-08-23 (r22 - r24):
- Add rcov task to Rakefile
- Add some tests
2006-08-20 (r9 - r21):
- Add a bunch of rdoc and rdoc infrastructure
- Add rake task to clean up errant whitespace
- Spin off a branch to remove a bunch of method injection in the generator code
- Rename some tests for clarity’s sake
- Replace NARF generation code with Ben’s generation code
- Update tests
- This broke indentation (will be fixed later)
- Add Plist::Emit.dump, so you can dump objects which don’t include Plist::Emit, update tests to match
- Fix a bug with the method that wraps output in the plist header/footer
2006-08-19 (r1 - r8):
- The beginnings of merging the plist project into the NARF plist library
(under the plist project’s name)
- fancier project infrastructure (more tests, Rakefile, the like)
- Add/update copyright notices in the source files
- Move a bunch of documentation out to README
- Split library into chunks
- Properly delete files when cleaning up from tests


{{site.footer-description}}
Email: {{site.email}}
Phone: {{site.phone}}0
© {{'now' | date: '%Y'}}. All rights reserved
Developed by webjeda


Test¶
Prior to running workspace tests, the workspace source files must be built. See Build, configure, and deploy.
In order to run tests:
- MongoDB must be installed, but not necessarily running.
- Shock must be installed, but not necessarily running.
- MySQL must be installed, but not necessarily
running.
- AppArmor must be configured to allow spawning of a mysql instance with files in non-default locations by the user running tests.
- The Handle Service must be installed, but not necessarily running.
- The Handle Manager must be installed, but not necessarily running.
See Service dependencies for more information about these test dependencies.
Next, copy the test.cfg.example
file to test.cfg
and fill in appropriately.
Finally:
make test
The tests currently take 20-30 minutes to run.


Deuteronomy 29:3
The great temptations which thine eyes have seen, the signs, and those great miracles:


Topics
- Overview of services
- Breakdown of certain services
- Current flow
- Questions
Gateway
- In a few projects, proxies the request to the api or client
- Creates a single entry for the cluster
- logs out requests / responses
- Gathers metrics for prometheus/grafana (response codes / response times)
RabbitMQ
- Queueing system
- Used as a tool to mitigate long running tasks that may slow down response times
- Used with MassTransit to auto handle consuming/retry/failure
Comparable/US
- Started as a small service to handle comparables
- Used more as a domain boundry for USA focused features
- contains proxy for SE/MLS/PR Api's
Notification
- Ipad Port of call
- Runs mostly off queued messages
- can accept http requests
Flow


MyAfya
HOME
ABOUT US
SERVICES
CONTACT
my afya comes first
jijue,jitibu!


Student Arrested for Isla Vista Assault
by Edhat StaffRockfire Grill at 6583 Pardall Road in Isla Vista
Update by edhat staff
November 22, 2019
A UC Santa Barbara (UCSB) student was arrested on November 6 on three misdemeanor charges of battery, public intoxication, and fighting in public after allegedly assaulting numerous people in Isla Vista, reports The Daily Nexus.
An edhat reader reported the incident earlier this month stating UCSB sent out an alert to students of a possible hate crime that took place outside Rockfire Grill on Pardall Road. The suspect was described as a white male who got into a fight with another male and called him a homophobic slur while also assaulting two women on the scene.
Third-year transfer student Tucker Steil was arrested by the Isla Vista Foot Patrol and held on a $2,500 bail.
Numerous witnessed stated the attack appeared to be an aggressive anti-gay attack, but the suspect has not been charged with a hate crime.
UCSB officials were criticized for not informing students of this incident which prompted the campus-wide notification the following week.
One of the female victims reportedly sustained a broken hand and a male victim sustained a concussion and broken nose.
By an edhat reader
November 15, 2019
Does anyone have more information on a violent assault and possible hate crime that took place in Isla Vista this week?
I received a notice from the University stated they received a report of a hate crime and are in connection with the victims.  This was outside Rockfire Grill on Pardall.
Outside of the notice from UCSB and people talking, I haven't seen any information or followup in local news. What's up?


Open Internet for everyone. Lantern is a free desktop application that delivers fast, reliable and secure access to the open Internet.
The most popular HTML, CSS, and JavaScript framework for developing responsive, mobile first projects on the web.
The http://FreeCodeCamp.com open-source codebase and curriculum. Practice coding by helping nonprofits.
A huge list of frontend development resources I collected over time. Sorted from general knowledge at the top to concrete problems at the bottom.
Material Design Lite Components in HTML/CSS/JS
Build cross platform desktop apps with web technologies


Graf-Python Module - PyGraph.py
Graph structure backing the ISO GrAF format.
The graph is undirected, composed of C{PyNode}s and C{PyEdge}s, each
backed by a C{list} to maintain the order of the nodes/edges and to
allow for quick traversals, and a hash map so nodes/edges can be found
quickly based on their ID
-
class PyGraph.PyGraph[source]
Class of PyGraph.
Methods
-
__init__()[source]
Constructor for PyGraph.
-
add_annotation_set(set)[source]
Add given C{PyAnnotationSet} to this C{PyGraph}.
| Parameters: | set – C{PyAnnotationSet} |
-
add_annotation_space(set)[source]
Add given C{PyAnnotationSpace} to this C{PyGraph}.
| Parameters: | set – C{PyAnnotationSpace} |
-
add_as_create(name, type)[source]
Create C{PyAnnotationSet} from given name, value and
add it to this C{PyGraph}.
| Parameters: |
- name – C{str}
- type – C{str}
|
-
add_aspace_create(as_id)[source]
Create C{PyAnnotationSpace} from given name, value and
add it to this C{PyGraph}.
| Parameters: |
- name – C{str}
- type – C{str}
|
-
add_edge(edge)[source]
Add C{PyEdge} to this C{PyGraph}.
| Parameters: | edge – C{PyEdge} |
-
add_edgeToFromID(id, fromID, toID)[source]
Create C{PyEdge} from id, fromID, toID and add it to
this C{PyGraph}.
| Parameters: |
- id – C{str}
- fromID – C{str}
- toID – C{str}
|
-
add_edge_create(id, fromNode=None, toNode=None)[source]
Create C{PyEdge} from id, fromNode, toNode and add it to
this C{PyGraph}.
| Parameters: |
- id – C{str}
- fromNode – C{PyNode}
- toNode – C{PyNode}
|
-
add_edge_from_to(fromNode, toNode)[source]
Create C{PyEdge} from fromNode, toNode and add it to
this C{PyGraph} id is created.
| Parameters: |
- fromNode – C{PyNode}
- toNode – C{PyNode}
|
-
add_node(node)[source]
Add C{PyNode} to this C{PyGraph}.
| Parameters: | node – C{PyNode} or C{str} |
-
find_edge(fromNode, toNode)[source]
Search for C{PyEdge} with its fromNode, toNode, either nodes or ids.
| Parameters: |
- fromNode – C{PyNode} or C{str}
- toNode – C{PyNode} or C{str}
|
| Returns: | C{PyEdge}
|


[§103F-105] Preventing impairment of federal funds. This chapter shall be liberally construed to not hinder or impede a state agency's application for, or receipt and use, of federal funds. [L 1997, c 190, pt of §2]


Deploying Ruby on Rails is easy
Taking your Rails application live has never been easier.
Thanks to the rise of Passenger aka mod_rails,
launching is now almost as easy as developing.
Passenger
aka mod_rails
The easiest deployment setup for Rails is Phusion Passenger aka mod_rails. It’s a module for nginx and Apache that automatically manages the back end. Just setup, launch, and enjoy.
Proxy setups
If you need more fine-grained control over your deployment setup, the common option is to use a front-end server like nginx and Apache combined with a proxy relay like HAProxy to cluster of Unicorns. That’s how Basecamp and a lot of other high-end deployments run.
JRuby on Rails
JRuby brings Rails to the Java Virtual Machine. This means that you can deploy Rails applications on app servers like Glassfish or Jetty. You can use Warbler to package your Rails application as a standard WAR. Great for slipping into the enterprise.
Automate with
Capistrano
Capistrano brings deployment automation to Rails whether you’re working with a single server or on a cluster of dozens. It was extracted from the Basecamp tool chain (like Rails) by core alumni Jamis Buck.
Hosting
While Rails hosting is now common place, there’s a handful of dedicated Rails hosting companies that have been around for a long time and supporting the community: Heroku, Rails Machine, Brightbox, and Engine Yard. If you’re just looking for a VPS, we recommend Rackspace (who gracefully donated slices for us to run Rails infrastructure on) or Linode.


This first step to work with SKY UX is to create your single-page application. You can create the local SKY UX application with the SKY UX CLI, but we recommend that you first set up a Git repo to store the source files for the SPA. You can create the repo in Visual Studio Team System or GitHub. Then when you create the local SKY UX application, the SKY UX CLI clones the repo and automatically pulls in the SKY UX template.
From the command prompt,
Enter
In the first prompt, specify a root directory for your project. The SKY UX CLI creates a folder with this name and prefixes it with "skyux-spa."
The root directory determines how to access the SPA because the URL for the home page includes the root directory after the base URL.
In the second prompt, specify the URL for your Git repo to store the source files for your application. You can use a Visual Studio Team System Git repo or a GitHub repo. The SKY UX CLI clones the repo and automatically pulls in the SKY UX template.
Internal Blackbaud developers should create repos and provision their applications through the SKY UX App Management Portal before they create local SKY UX applications.
After the SKY UX CLI downloads the SKY UX template project and installs its dependencies, the command prompt displays the directory name: "SPA [directory name] created in directory "skyux-spa-[directory name]."
For information about the default items that the template provides in a SKY UX single-page application, see the template items reference.