text:
---
uid: cluster-overview
title: Akka.Cluster Overview
---

# Akka.Cluster Overview

> [!IMPORTANT]
> See "[Reliable Akka.NET Message Delivery with Akka.Delivery](xref:reliable-delivery)" for tips on how to achieve reliable messaging over Akka.Remote and Akka.Cluster.

## What Is a "Cluster"?

A cluster represents a fault-tolerant, elastic, decentralized peer-to-peer network of Akka.NET applications with no single point of failure or bottleneck. Akka.Cluster is the module that gives you the ability to create these applications.

## What Does Akka.Cluster Do?

The best way to begin introducing Akka.Cluster is with brief overview of what it does. Akka.Cluster is the [package](https://www.nuget.org/packages/Akka.Cluster/) that brings clustering support to Akka.NET, and it accomplishes this by adding the following capabilities to Akka.NET:

* Makes it easy to create peer-to-peer networks of Akka.NET applications
* Allows peers to automatically discover new nodes and removed dead ones automatically with no configuration changes
* Allows user-defined classes to subscribe to notifications about changes in the availability of nodes in the cluster
* Introduces the concept of "roles" to distinguish different Akka.NET applications within a cluster
* Allows you to create clustered routers, which are an extension of the built-in Akka.NET routers, except that clustered routers automatically adjust their routees list based on node availability.

## Benefits of Akka.Cluster

In short, these are the benefits of a properly designed cluster:

* **Fault tolerant**: clusters recover from failures (especially network partitions) elegantly.
* **Elastic**: clusters are inherently elastic, and can scale up/down as needed.
* **Decentralized**: it's possible to have multiple **equal** replicas of a given microservice or piece of application state running simultaneously throughout a cluster
* **Peer-to-peer**: New nodes can contact existing peers, be notified about other peers, and fully integrate themselves into the network without any configuration changes.
* **No single point of failure/bottleneck**: multiple nodes are able to service requests, increasing throughput and fault tolerance.

## How Is Clustering Different From Remoting?

Akka.Cluster is a layer of abstraction on top of Akka.Remote, that puts Remoting to use for a specific structure: clusters of applications. Under the hood, Akka.Remote powers Akka.Cluster, so anything you could do with Akka.Remote is also supported by Akka.Cluster.

Generally, Akka.Remote serves as plumbing for Akka.Cluster and other "high availability" modules within Akka.NET. You would generally only use Akka.Remote by itself in scenarios that don't require the elasticity and fault-tolerance needs that Akka.Cluster provides.

Essentially, Akka.Cluster extends Akka.Remote to provide the basis of scalable applications.

## Use Cases

Akka.Cluster lends itself naturally to [high availability](https://en.wikipedia.org/wiki/High_availability) scenarios.

To put it bluntly, you should use clustering in any scenario where you have some or all of the following conditions:

* A sizable traffic load
* A non-trivial task to perform
* An expectation of fast response times
* The need for elastic scaling (e.g. bursty workloads)
* A microservices architecture

Some of the use cases where Akka.Cluster emerges as a natural fit are in:

1. Analytics
2. Marketing Automation
3. Multiplayer Games
4. Devices Tracking / Internet of Things
5. Alerting & Monitoring Systems
6. Recommendation Engines
7. Dynamic Pricing
8. ...and many more!

## Key Terms

Akka.Cluster is concept-heavy, so let's clarify a few terms:

* **Node**: a logical member of a cluster.
* **Cluster**: a set of nodes joined through the membership service. Multiple Akka.NET applications can be a part of a single cluster.
* **Gossip**: underlying messages powering the cluster itself.
* **Leader**: single node within the cluster who adds/removes nodes from the cluster.
* **Role**: a named responsibility or application within the cluster. A cluster can have multiple Akka.NET applications in it, each with its own role. A node may exist in 0+ roles simultaneously.
* **Convergence**: when a quorum (simple majority) of gossip messages agree on a change in state of a cluster member.

## Enabling Akka.Cluster

Now that we've gone over some of the concepts and distributed programming concerns behind Akka.Cluster's design, let's focus on how to actually use it inside our own Akka.NET applications.

![Steps to enable Akka.Cluster](/images/how-to-enable-akka-cluster.png)

The first step towards using Akka.Cluster is to install the [Akka.Cluster NuGet package](http://www.nuget.org/packages/Akka.Cluster/ "Akka.Cluster NuGet Package"), which you can do inside the Package Manager Console in Visual Studio:

```console
PM> Install-Package Akka.Cluster
```

Once you've installed Akka.Cluster, we need to update our HOCON configuration to turn on the `akka.actor.provider = cluster`, configure an Akka.Remote transport, and enable at least 1 seed node.

> [!NOTE]
> Akka.Cluster depends on Akka.Remote.

### Seed Node Configuration

```xml
akka {
    actor.provider = cluster
    remote {
        dot-netty.tcp {
            port = 8081
            hostname = localhost
        }
    }
    cluster {
        seed-nodes = ["akka.tcp://ClusterSystem@localhost:8081"]
    }
}
```

In this instance, we're configuring this node to act as a seed node to the cluster, so it uses *its own Akka.NET `Address`* inside the `cluster.seed-nodes` property.

You can, and should, specify multiple seed nodes inside this field - and seed nodes should refer to themselves.

> [!NOTE]
> If you're using dedicated seed nodes (such as [Lighthouse](https://github.com/petabridge/lighthouse)), you should run at least 2 or 3. If you only have one seed node and that machine crashes, the cluster will continue operating but no new members can join the cluster!

#### Non-Seed Node Configuration

```xml
akka {
    actor.provider = cluster
    remote {
        dot-netty.tcp {
            port = 0 #let os pick random port
            hostname = localhost
        }
    }
    cluster {
        seed-nodes = ["akka.tcp://ClusterSystem@localhost:8081"]
    }
}
```

In this case, we've created a non-seed node - it binds its Akka.Remote transport to a random port assigned by the operating system, but it connects to the seed node we assigned in the previous section.

> [!NOTE]
> All nodes in an Akka.NET cluster must have the same `ActorSystem` name.

This is important! Even if you're running multiple separate Akka.NET applications inside a single Akka.NET cluster, they must all share the same `ActorSystem` name - otherwise they will not be permitted to join the cluster.

## Cluster Gossip

**This is the most important concept within `Akka.Cluster`.** This is how nodes are able to join and leave clusters without any configuration changes.

[Gossip](https://en.wikipedia.org/wiki/Gossip_protocol) is the ongoing flow of messages that are passed between nodes in a cluster, updating cluster members of the state of each member of the cluster.

When a node wants to join a cluster, it must first contact one of its configured seed nodes. Once the node has been able to connect to one seed node, it will begin receiving gossip messages containing information about other members of the cluster.

![Akka.Cluster gossip propagation](/images/akka-cluster-gossip.png)

So in the example above:

1. **B** contacts its configured seed node **A** and requests to join the cluster.
2. **A** marks **B** as up and begins to share gossip information with **B** about other nodes in the cluster, but there aren't any other nodes connected at the moment.
3. **C** contacts **A** and requests to join the cluster.
4. **A** welcomes **C** to the cluster and begins sharing gossip information with node **C**.
5. **B** and **C** are both notified about each other by node **A**.
6. **B** and **C** connect to each other and establish communication.

Gossip messages will occur regularly over time whenever there is any change in the status of a member of the cluster, such as when a node joins the cluster, leaves the cluster, becomes unreachable by other nodes, etc.

Generally, you will not interact with gossip messages at the application level. But you do need to be aware of them and know that they power the cluster. To learn more about gossip and event types, see [Working With Cluster Gossip](xref:cluster-extension#working-with-cluster-gossip).

## Nodes

A node is a logical member of a cluster. A node is defined by the address at which it is reachable (hostname:port tuple). Because of this, more than one node can exist simultaneously on a given machine.

### Seed Nodes

A seed node is a well-known contact point that a new node must contact in order to join the cluster. Seed nodes function as the service-discovery mechanism of Akka.Cluster.

> [!NOTE]
> [Lighthouse](https://github.com/petabridge/lighthouse) is a pre-built, dedicated seed node tool that you can use. It's extremely lightweight and only needs to be upgraded when Akka.Cluster itself is upgraded. If you're hosted on a platform like Azure or AWS, you can also tap into the platform-specific APIs to accomplish the same effect.

## How a Cluster Forms

This is what the process of a node joining the cluster looks like:

Clusters initially consist of two distinct parts:

1. **Seed nodes** - nodes that reside at well-known locations on the network and
2. **Non-seed nodes** - nodes whose initial locations are unknown, and these nodes contact seed nodes in order to form the cluster.

We can picture the initial state of a 5-node Akka.NET cluster to look like this:

![Initial state of a 5-node Akka.NET cluster](/images/akka-cluster-concept.png)

**A** and **B** are both seed nodes, and listen on IP address / port combinations that are baked into the configurations of **C, D,** and **E**.

**A** and **B** also know *each other's locations*, so they can communicate with each other initially also.

> [!NOTE]
> A special rule applies the first time a cluster forms: the first seed node declared in a `akka.cluster.seed-nodes` list *must be up*. Otherwise the cluster will not form. This is designed to prevent a split brain from forming the first time a cluster launches. And in general, as a best practice: **always use an identical seed node list on every node, including the seed nodes**. This will give you the most consistent behavior and results.

![Akka.Cluster nodes begin attempting to join each other, beginning with seed nodes](/images/akka-cluster-joining.png)

All nodes initially attempt to connect to a seed node - in this instance the nodes are configured in the following way:

* **E** knows how to contact **B**;
* **C** and **D** know how to contact **A**; and
* **A** and **B** know how to contact each other.

![Akka.Cluster elects a leader, who begins making decisions about which nodes are up](/images/akka-cluster-leader.png)

During the process of initial contact within the cluster, a leader will be elected. In this case node **A** is elected to be the leader of the cluster.

**A** will begin marking nodes as up, beginning with the nodes it knows about: **A,B,C,** and **D**. **A** does not know about node **E** yet, so it's not marked as up.

Gossip information about the membership of the cluster will begin to spread to all nodes, and the nodes will all begin to connect to each other to form a mesh network.

![Akka.Cluster forms a ring / mesh network with all nodes connected to all nodes](/images/akka-cluster-ring.png)

After the gossip has had a chance to propagate across all nodes and the leader has marked everyone as up, every node will be connected to every other node and the cluster will have formed. Every node can now participate in any user-defined cluster operations.

### Leader Election

The cluster leader is chosen by a leader election algorithm that randomly picks a leader from the available set of nodes when the cluster forms. Usually, the leader is one of the seed nodes.

#### Cluster vs. Role Leader

Each role within the cluster also has a leader, just for that role. Its primary responsibility is enforcing a minimum number of "up" members within the role (if specified in the [cluster config](xref:cluster-configuration)).

### Reachability

Nodes send each other [heartbeats](<https://en.wikipedia.org/wiki/Heartbeat_(computing)>) on an ongoing basis. If a node misses enough heartbeats, this will trigger `unreachable` gossip messages from its peers. The leader will wait for the node to either become reachable again, restart or get downed. Until that happens, the cluster is not in a consistent state and the leader indicates that it is unable to perform its duties. If the gossip from a quorum of cluster nodes agree that the node is unreachable ("convergence"), the leader will mark it as down and begin removing the node from the cluster. You can control how long the cluster waits for unreachable nodes through the auto-down-unreachable-after setting.

When marked as unreachable, the node can restart and join the cluster again, however the association will only be formed if that node is identified as the same node that became unreachable. If you use dynamic addressing (port 0), starting a node again might result in a different port being assigned upon restart. The result of that is that the cluster remains in an inconsistent state, waiting to the unreachable node to either become reachable or get downed.

A node might also exit the cluster gracefully, preventing it from being marked as unreachable in the first place. Akka.net uses IDowningProvider to take the nodes through all the stages of exiting the cluster. Starting in Akka.NET 1.2 [CoordinatedShutdown](https://github.com/akkadotnet/akka.net/releases/tag/v1.2) was introduced allowing the user to easily invoke that mechanism.

## Location Transparency

[Location transparency](xref:location-transparency) is the underlying principle powering all of Akka.Remote and Akka.Cluster. The key point is that in a cluster, it's entirely possible that the actors you interface with to do work can be living on any node in the cluster... and you don't have to worry about which one.

## Additional Resources

<!-- markdownlint-disable MD033 -->
<iframe width="560" height="315" src="https://www.youtube.com/embed/mUTKvGyxbOA" frameborder="0" allowfullscreen></iframe>
<!-- markdownlint-enable MD033 -->

* [Cluster Member Roles](xref:member-roles)
* [How to Create Scalable Clustered Akka.NET Apps Using Akka.Cluster](https://petabridge.com/blog/intro-to-akka-cluster/)
* [Video: Introduction to Akka.Cluster](https://www.youtube.com/watch?v=mUTKvGyxbOA)
* [Gossip Protocol](https://en.wikipedia.org/wiki/Gossip_protocol)
* [High-availability scenarios](https://en.wikipedia.org/wiki/High_availability)
* [Microservices](http://martinfowler.com/articles/microservices.html)

branch_name: refs/heads/dev

gha_language: C#


text:
<img src="square-logo.svg" width=200 height=200 align="right">

This repository contains some example components meant for educational/inspirational
purposes. These are components that we open source to encourage experimentation but
these are components that are **not officially supported**. There will be some tests
as well as some documentation but this project should be considered a community project,
not something that is part of core Rasa.

# Documentation

You can find the documentation for this project [here](https://rasahq.github.io/rasa-nlu-examples/).
# Components

The following components are implemented.

### Meta

- `rasa_nlu_examples.meta.Printer`: a printer that's useful for debugging

### Dense Featurizers

- `rasa_nlu_examples.featurizers.dense.FastTextFeaturizer`: pretrained fasttext embeddings [link](https://fasttext.cc/)
- `rasa_nlu_examples.featurizers.dense.BytePairFeaturizer`: pretrained byte-pair embeddings [link](https://nlp.h-its.org/bpemb/)

repository: govindarajan/rasa-nlu-examples

branch_name: refs/heads/master

extension: md

license_type: permissive

repo_name: govindarajan/rasa-nlu-examples


text:
boxbilling CHANGELOG
====================

This file is used to list changes made in each version of the `boxbilling` cookbook.

## v1.0.0 (2015-09-01)

* Install BoxBilling 4 by default, adds `node['boxbilling']['version']` attribute (**breaking change**).
* Update chef links to use *chef.io* domain.
* Update contact information and links after migration.
* metadata: Add `source_url` and `issues_url`.

* Documentation:
 * README:
  * Use markdown tables.
  * Improve description.

* Testing:
 * Replace all bats integration tests by [Serverspec](http://serverspec.org/) and [infrataster](https://github.com/ryotarai/infrataster) tests.
 * Fix *already initialized constant* warning.
 * Gemfile: Update RuboCop to `0.33.0`.
 * Move ChefSpec tests to *test/unit*.
 * Add a Guardfile.
 * Rakefile: Add clean task.
 * Travis CI: Run tests on Ruby `2.2`.

## v0.9.0 (2015-05-19)

* Add custom HTTP headers support in nginx.
* Update RuboCop to version `0.31.0`.

## v0.8.0 (2015-03-13)

* `RecipeHelpers#boxbilling_upload_cookbook_file`: Upload files to the root directory instead of *bb-uploads* (disallowed in robots.txt).

## v0.7.0 (2015-02-23)

* Fix `boxbilling_api[admin/system/params]` notifications.
* Disable PHP inside *bb-uploads* and *bb-data* directories.

## v0.6.0 (2015-02-13)

* `boxbilling_api`:
 * Use returned id when updating after a create.
 * Fix method name typo.
 * Use passed args when reading list.
 * Improved handling of borderline cases.
 * Fix condition on same_item?.
 * Handle paths that have slug field.

## v0.5.0 (2015-02-08)

* Update boxbilling when `'download_url'` points to a new version.
* `boxbilling_api`: Add `same_item?` to compare primary keys, support for `'admin/email/template'`.
* Calculate debug mode.
* Fix all RuboCop offenses (big code refactor).
* README: Add codeclimate badge.

## v0.4.1 (2015-01-21)

* Fix disabling nginx default site.

## v0.4.0 (2015-01-20)

* Add nginx support.
* Small improvements.
* Unit tests against Chef 11 and 12.

## v0.3.0 (2015-01-03)

* htaccess: Fix Apache `2.4` support.
* Fix Ubuntu `14` support.
* Add Fedora and RedHat support.
* Add integration tests.
* Update to use `ssl_certificate` cookbook version `1.1.0`.
* metadata: Use pessimistic operator for cookbook versions.
* Enable ChefSpec coverage.
* Gemfile: Use foodcritic fixed version.
* Update license year.

## v0.2.1 (2014-12-25)

* `boxbilling_api`: fix encrypted attributes decryption outside chef solo.

## v0.2.0 (2014-12-18)

* Add BoxBilling `4` support.
* Remove `node['boxbilling']['api_config']['enabled']` attribute from documentation.
* Create writable directory recursively.
* metadata:
 * Fix attribute types.
 * Lock `database` cookbook version.
* Fix version regular expression.
* Refactor ignore failure exception logic.
* Homogenize license headers.
* Add Vagrantfile.
* ChefSpec matchers: Add `boxbilling_api` locator.
* Unit tests integrated with `should_not` gem.
* ChefSpec unit tests clean up.
* Update ChefSpec tests to `4.1`.
* Gemfile: Update `vagrant-wrapper` gem to `2`.
* Berksfile: Document `local_cookbook` method.
* Move *test/kitchen/cookbooks/boxbilling_test* to *test/cookbooks/boxbilling_test*.
* TESTING.md: Some small improvements.
* README:
 * Clean up examples.
 * Small improvements.

## v0.1.1 (2014-11-13)

* Attributes: disable `['encrypt_attributes']` by default.
* Remove `node['boxbilling']['api_config']['enabled']` attribute (not needed).
* Rakefile: include kitchen only in integration tests.
* Gemfile:
 * Update to Berksfile 3.
 * Use `vagrant-wrapper` gem.
 * Add integration groups and disable them in travis-ci.

## v0.1.0 (2014-08-28)

* Initial release of `boxbilling`

repository: vgadreau/demo

repo_name: vgadreau/demo


text:
# Alerts

## Alerts

![alert_01](assets/components/alerts/img/01.png)

- Spec for default info message

![alert_02](assets/components/alerts/img/02.png)

- Spec for messages with action

![alert_03](assets/components/alerts/img/03.png)

- Spec for small devices

![alert_04](assets/components/alerts/img/04.png)

### Restrictions:
- Alerts closable with actions are incompatibles

license: MIT

repository: anapanadero/exo-design-system

repo_name: anapanadero/exo-design-system


text:
# Akka.NET [![Build status](https://ci.appveyor.com/api/projects/status/lstkbcrlphyb5bwp/branch/coreclr?svg=true)](https://ci.appveyor.com/project/ravengerUA/akka-net/branch/coreclr)

![Akka.NET logo](documentation/icons/AkkaNetLogo.Normal.png)

[![Gitter](https://badges.gitter.im/Join%20Chat.svg)](https://gitter.im/akkadotnet/akka.net?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)

[![Issue Stats](http://www.issuestats.com/github/akkadotnet/akka.net/badge/pr)](http://www.issuestats.com/github/akkadotnet/akka.net)
[![Issue Stats](http://www.issuestats.com/github/akkadotnet/akka.net/badge/issue)](http://www.issuestats.com/github/akkadotnet/akka.net)

## [Akka.NET Current Roadmap](https://petabridge.com/blog/akkadotnet-2016-roadmap/)

**Akka.NET** is a community-driven port of the popular Java/Scala framework [Akka](http://akka.io) to .NET.

* Subscribe to the Akka.NET dev feed: https://twitter.com/AkkaDotNet  (@AkkaDotNet)
* Support forum: https://groups.google.com/forum/#!forum/akkadotnet-user-list
* Mail<EMAIL_ADDRESS>* Stack Overflow: http://stackoverflow.com/questions/tagged/akka.net

### Documentation and resources

#### [Akka.NET Community Site](http://getakka.net)

### Install Akka.NET via NuGet

If you want to include Akka.NET in your project, you can [install it directly from NuGet](https://www.nuget.org/packages/Akka)

To install Akka.NET Distributed Actor Framework, run the following command in the Package Manager Console

```
PM> Install-Package Akka
PM> Install-Package Akka.Remote
```

And if you need F# support:

```
PM> Install-Package Akka.FSharp
```

### Contributing
#### Where Can I Contribute?
***[Issues for the Next Release (v1.1)](https://waffle.io/akkadotnet/akka.net?milestone=Akka.NET%20v1.1)***

[![Critical Issues](https://badge.waffle.io/akkadotnet/akka.net.svg?label=help%20wanted&title=Issues Needing Help Now!)](http://waffle.io/akkadotnet/akka.net)

[![Stories Up For Grabs](https://badge.waffle.io/akkadotnet/akka.net.svg?label=up%20for%20grabs&title=General Issues Up For Grabs)](http://waffle.io/akkadotnet/akka.net)

> *All contributions are welcome! Please consider the [issues categorized in the `Help!` column](http://waffle.io/akkadotnet/akka.net) first, as they are areas we could really use your help :)*

#### Contribution Guidelines
If you are interested in helping porting Akka to .NET please take a look at [Contributing to Akka.NET](http://getakka.net/docs/Contributing%20to%20Akka).

Our [docs](http://getakka.net/docs/) are always a work in progress—to contribute to docs, please see the [docs contribution guidelines here](http://getakka.net/docs/Documentation%20guidelines).

#### Builds
Please see [Building Akka.NET](http://getakka.net/docs/Building%20and%20Distributing%20Akka).

To access unstable nightly builds, please [see the instructions here](http://getakka.net/docs/akka-developers/nightly-builds).

### Support


text:
# Fast DNS Query Tool

A very fast DNS query tool. It can run multiple threads to query a single DNS
server very quickly.

## Installation

Requires Python 3.5 or higher. Requires the `dnspython` library.

    $ /opt/lcogt-python35/bin/pvenv env
    $ source env/bin/activate
    $ pip install --upgrade pip && pip install -r requirements.txt
    $ ./dnsfast --help

## Runtime Options

Please see `dnsfast --help`:

    usage: dnsfast [-h] [-w WORKERS] [-q QUERY] [-c COUNT] [-d DELAY] [-s SERVER]
                   [-p PRINTEVERY]

    optional arguments:
      -h, --help            show this help message and exit
      -w WORKERS, --workers WORKERS
                            Number of workers to run in parallel
      -q QUERY, --query QUERY
                            Hostname to query
      -c COUNT, --count COUNT
                            Number of queries to run
      -d DELAY, --delay DELAY
                            Delay between each query (ms)
      -s SERVER, --server SERVER
                            Nameserver to query
      -p PRINTEVERY, --printevery PRINTEVERY
                            Print status updates every N queries

## Example Output

    $ ./dnsfast -q configdb.lco.gtn -c 10000 -p 1000 -s <IP_ADDRESS>
    Starting testing...
    Query Servers: <IP_ADDRESS>
    Query Hostname: configdb.lco.gtn
    Number of Queries: 10000
    Delay after each query: 0 ms
    Number of concurrent workers: 5

    Processed 1000/10000 results (0.88 s elapsed, 1137.49 QPS) -> NOERROR=1000
    Processed 2000/10000 results (1.65 s elapsed, 1209.89 QPS) -> NOERROR=2000
    Processed 3000/10000 results (2.43 s elapsed, 1234.42 QPS) -> NOERROR=3000
    Processed 4000/10000 results (3.21 s elapsed, 1244.62 QPS) -> NOERROR=4000
    Processed 5000/10000 results (3.99 s elapsed, 1254.62 QPS) -> NOERROR=5000
    Processed 6000/10000 results (4.77 s elapsed, 1258.36 QPS) -> NOERROR=6000
    Processed 7000/10000 results (5.54 s elapsed, 1264.04 QPS) -> NOERROR=7000
    Processed 8000/10000 results (6.33 s elapsed, 1264.60 QPS) -> NOERROR=8000
    Processed 9000/10000 results (7.10 s elapsed, 1267.70 QPS) -> NOERROR=9000
    Processed 10000/10000 results (7.88 s elapsed, 1269.56 QPS) -> NOERROR=10000

    Elapsed time: 7.89 s Queries: 10000 QPS: 1267.64
    NOERROR=10000

## License

This project is licensed under the MIT License. Please refer to the
[LICENSE](LICENSE) file in this repository for further information.


text:
# Users & Privileges

When connecting to a database a user and password is needed. The default user
is called `root` and currently has no password.

The `root` user is the administrative user. It has all privileges, can access
all the data and can execute any query. For local development this might be just
ok. But on a production server, this is actually a really bad idea. Someone with
bad intentions can easily guess this combination of username and password and
can just do whatever he wants. He can steal all data, change data or even delete
it.

MySQL enables you to define multiple users for a single server instance. This means
that you can create as many users, with their own username and password, as you want.
On top of that each user can have its own set or privileges, telling what it can
and cant do. For example you can create users that only need read privileges on
a single table where as another user can only create rows (without the ability to
read them.)

## Hosts

MySQL makes a difference for users depending from what machine they connect to the
database. This means that someone that connects with the username `root` from the
same machine as where the database server is running on `localhost`,
is not the same user that connects with username `root` from another computer on the
network or the internet.

Each username is tied to an interface it connects on. This is called the 'host'
part of the username.

If a server has 1 network interface with the ip `<IP_ADDRESS>`, then users can use
this connect interface to connect to the database. Every server/computer has also
a loopback interface that has the ip `<IP_ADDRESS>` also known as `localhost`.
MySQL/MariaDB can thus make a distinction between connections coming from each of
the two interfaces. This enables the database to control which machines are allowed
to make connections together with the corresponding username.

It is also possible to allow connections from any host. In this case a `%` wildcard
can be used.

By default MySQL and MariaDB are configured to listen only to connections on `localhost`.
This means that if you want to connect from a remote machine, you need to configure
this first.

## Users

To connect to the database with the `root` user you can use the following command:

```bash
mysql -u root -p
```

If the `root` user has no password, the `-p` can be omitted.

 Keep in mind that the database
server will also take the machine from where the connection is initiated
from into account. By default `root` is only allowed to connect from `localhost`.
This means that nobody can get access to your database, unless they have access to
your computer. Remote connections are not allowed.

In development situations this might be tolerated. On production environments this
is a real security problem. It's best to create a different user for each application
that needs to connect to the database.

### Changing passwords

It might be an good idea to change the root password in order to prevent unwanted
access to your database. This can be done once logged in, with the following command:

```sql
ALTER USER 'root'@'localhost' IDENTIFIED BY 'password';
```

Note that the full username consist out of the username `root` and hostname `localhost`,
separated with an `@` sign.

The `ALTER USER` query expects a password that is designated by the `IDENTIFIED BY`
clause. You can place your new password there in order to change the current password.

Note that if you change the `root` password, make sure you remember the password.
If it's the only user with adequate permissions, you might block yourself out of
your own database. If you ever get in this situation, remember that you can get
access again with a specific set of commands when starting the server service.

### Creating users

Creating users is done in a similar way. This can be done using a `CREATE USER`
query:

```sql
CREATE USER 'thomas'@'localhost' IDENTIFIED BY 'my_secret_password';
```

The query above will create a user named `thomas` that is only allowed to connect
from `localhost`. His password is `my_secret_password`.

The same username can be used multiple times if you change the host part. Each user
can have a different password for each allowed host.

```sql
CREATE USER 'thomas'@'%' IDENTIFIED BY 'anotherpassword';
```

Different privileges can be assigned to the different users allowing them to do
different things depending on where they make a connection from. For example if
'thomas' connects from a remote machine, the privileges can be more restricted
in order to prevent security issues.

### Deleting users

When users are no longer needed, they can be delete with the `DROP USER` query.

```sql
DROP USER 'thomas'@'localhost';
```

## Privileges

Each user can have its own set of privileges. The privileges allow users to give
permissions to some actions and deny others. This enables fine grained control
over who can do what.

For example in a company, sales people might need to only insert invoices into the
database, but might not be allowed to read them. On the other hand, accountants
might only be able to read invoiced, but not create them.

### Multiple isolated databases

An other way in which privileges are used is to allow certain users only to have
access to a single database. This principle is used by many shared hosting services.

This allows a single database server to host many databases for multiple users that
should not get access to each others databases.

### Adding Permissions

If you create a new user, the user does not have any privileges. This means the user
can only log in and do nothing. In order to give access to some tasks and resources
permissions must be created (granted) to that user.

```sql
GRANT ALL PRIVILEGES ON forta.products
TO 'thomas'@'localhost';
```

In this example, the user `thomas` that connects from `localhost` is granted all
privileges for the `products` table in the `forta` database.

Thomas can do anything only within this database. Thomas has no access nor is he
able to see any other table in the `forta` database or any other database.

Wildcards can be used for tables and databases in order to grant access to multiple
tables or databases as well.

The following query will give thomas permissions to all the tables in the forta database:

```sql
GRANT ALL PRIVILEGES ON forta.*
TO 'thomas'@'localhost';
```

The following query will give thomas permissions to all databases and all tables
(just like the root user):

```sql
GRANT ALL PRIVILEGES ON *.*
TO 'thomas'@'localhost';
```

Instead of granting `ALL PRIVILEGES`, which just allows anything, it is also possible
to grant specific privileges.

Here is a list of privileges that can be used to `GRANT`.

| Name | Description |
| --- | --- |
| ALL PRIVILEGES | You can do anything the database allows |
| CREATE | Allows the user to create new tables or databases |
| DROP | Allows the user to delete tables or databases |
| DELETE | Allows the user to delete rows from tables |
| INSERT | Allows them to insert rows into tables |
| SELECT | Allows them to use select queries to read data from tables |
| UPDATE | Allows them to update table rows |
| GRANT OPTION | Allows them to grant and remove other users' privileges |

Note: this is just a summary of the most important grants. Many others exist.

In the following example, Thomas can only read and insert rows into any table of
the forta database. He is not allowed to delete or update them.

```sql
GRANT SELECT, INSERT ON forta.*
TO 'thomas'@'localhost';
```

### Showing users grants

In order to view your privileges you can run the following query:

```sql
SHOW grants;
```

You can also request the grants of any other user (if you have the permission to
do this).

```sql
SHOW GRANTS FOR 'root'@'localhost';
```

## Revoking rights of a user

When needed you can also remove permissions from user by revoking grants.

```sql
REVOKE UPDATE ON forta.products
FROM 'thomas'@'localhost'
```

This will remove the `UPDATE` grant for thomas connecting from localhost.

## Logging in

We can now connect to the database using the credentials of the new user

```text
mysql -u username -p -h <IP_ADDRESS>;
```

* `-p` specifies that the user requires a password to be filled in
* `-h` specifies that the user wants to access a database on another host
* `<IP_ADDRESS>` is the IP address of the machine with the database

repository: sillevl/course-databases

gha_language: JavaScript

gha_license_id: MIT

repo_name: sillevl/course-databases


text:
# Emulated-Android-Arrow.js
![npm](https://img.shields.io/npm/dt/emulated-android-arrow.js)
> Smooth vanilla JavaScript arrow slider like Android launcher's arrow for website.

[Website for preview](https://kenclaron.github.io/kenclaron/)

## Table of contents
- [Features](#features)
- [Getting started](#getting-started)
  - [Syntax](#syntax)
  - [Example](#example)
- [License](#license)
- [Browser support](#browser-support)
- [Author](#author)

## Features

- Cross-browser support
- Desktop and mobile platforms support
- Supports custom settings (check out the available [syntax](#syntax))

## Main

```text
dist/
├── emulated-android-arrow.js
└── emulated-android-arrow.min.js   (compressed)
```

## Getting Started

### Installation

```
npm install emulated-android-arrow.js
```

In browser:

```html
<script src="/path/to/emulated-android-arrow.js"></script>
```

### Usage

#### Syntax

```js
  new EmulatedAndroidArrow(parent, crossSupport, mobile, direction);
```

- **parent**
  - Type: `HTMLElement`
  - The HTMLElement as parent for arrow element.

- **crossSupport** (optional)
  - Type: `Boolean`
  - 180 degree rotation on mobile devices when true. (default: true)

- **mobile** (optional)
  - Type: `Boolean`
  - True: Only mobile devices | False: All devices (default: false)

- **direction** (optional)
  - Type: `Number`
  - Starting direction (0: none, 1: top, -1: bottom) (default: 0)

#### Example

```js
  new EmulatedAndroidArrow(document.body, true, false, 1);
```

## License

The Emulated-Android-Arrow.js licensed under the [MIT license](https://opensource.org/licenses/MIT).

## Browser support

- Chrome (49.0.2623 or latest)
- Firefox (45.0 or latest)
- Opera (36.0.2130.32 or latest)
- Edge (25.10586/EdgeHTML 13.10586 or latest)
- Safari (9.0 or latest)

## Author

> You can express your gratitude by clicking on one of the links

- [Personal website](https://kenclaron.github.io/kenclaron/)
- [VK](https://vk.com/club190729942)

___________________________________

[↑ back to top](#table-of-contents)


text:
---
layout: post
author: Maxim Braekman
title: Expose a WSDL through APIM
description: Want to find out how you can expose a WSDL through API Mangement?
image: ./img/apim-expose-wsdl.jpg
tags: [API Management, SOAP]
caption: "API Management"
---
## Expose WSDL through SOAP APIM endpoint

Creating a new SOAP-based API within API Management is easy, just import the WSDL and you're done. But this API lacks an endpoint by which the actual WSDL is being exposed, as would be the case on a traditional SOAP-service.
Luckily, there is an easy way to achieve this, so you don't have to share the WSDL in any other way.

## Steps
- [Overview](#overview)
- [Provision the required storage account](#provision-the-required-storage-account)
- [Create a new operation](#create-a-new-operation)
- [Alternative setup](#alternative-setup)
- [Set the policy](#set-the-policy)

### Overview
Before we get started, let's give an overview of how we can expose the WSDL through an API-endpoint and how everything will be connected.

Since a diagram gives a better overview than a whole bunch of text, have a look at the diagram added underneath and consider the fact that in this case we are going to expose a WSDL, stored as a blob inside a storage account, without requiring any custom code on our backend.

[![High level overview](../../../../img/posts/azure-apim-wsdl-endpoint/high-level-overview.png)  ](../../../../img/posts/azure-apim-wsdl-endpoint/high-level-overview.png)

### Provision the required storage account
First, you need some place to store the actual WSDL-file and while you could use many different services to do so, a Blob container within a Storage Account does seem like to cheapest/best option.

For this purpose, an existing Storage Account can be re-used, by adding a new Blob container, specifically for this purpose.  As this container will only contain WSDL-files *(hopefully as less as possible)*, which should be made publicly available to whoever needs it, we can set the **public access level** of this container to '*Public read access for blobs only*'.
While this does allow anonymous requests to access the blobs within the container - which isn't very secure - for this purpose that is OK, since you want the WSDL to be publicly available any way.

![Set public access level](../../../../img/posts/azure-apim-wsdl-endpoint/set-public-access.png)

### Create a new operation
Assuming you've already created an API Management instance and added an API based on the prepared WSDL, it is time to extend the SOAP API with a WSDL-endpoint.

Add a new **GET**-operation to the API and set the display name to something such as 'Expose WSDL'.
However, since this is a SOAP API, we are forced to set a specific soapAction as part of the URL.

![Set soapAction](../../../../img/posts/azure-apim-wsdl-endpoint/apim-specify-soapaction.png)

In this case, we can simply set the URL to **/?soapAction=wsdl**.
While, this doesn't match the exact structure of a regular SOAP API, in which you can access the WSDL via '*?wsdl*' or '*?singleWsdl*', it's coming close.

![Create new operation](../../../../img/posts/azure-apim-wsdl-endpoint/apim-create-new-operation.png)

As part of the communication with your client, you can simply state the WSDL can be accessed through the following URL:
https://mbraekman-dev-we-apim.azure-api.net/api/soap/?soapAction=wsdl

### Alternative setup
Don't want to tell people they have to browse to a specific URL containing '*/?soapAction=wsdl*'?
No problem, there is an alternative way of achieving the default SOAP-behavior regarding exposing a WSDL-file.

Instead of adding a new operation to the existing SOAP API within API Management, you can also choose a add a new blank API instead.

*Note: This API can be re-used to expose all WSDL's for any of the SOAP API's you created.*

When creating this WSDL API, make sure to leave the *API URL Suffix empty*, so can you specify this suffix from within every single operation to match the URL of the API for which the WSDL is to be exposed.

[![Create WSDL API](../../../../img/posts/azure-apim-wsdl-endpoint/wsdl-api.png)  ](../../../../img/posts/azure-apim-wsdl-endpoint/wsdl-api.png)

Inside this new API, add a **GET**-operation and make sure to use the display name property to refer to the corresponding API, but also pay attention to set the URL of this operation to match the base-URL of you SOAP API, followed by the suffix '*?wsdl*'.

![Create new WSDL Operation](../../../../img/posts/azure-apim-wsdl-endpoint/wsdl-api-new-operation.png)

In turn, this means your WSDL will be exposed through an URL, matching the traditional way of exposing a WSDL on your SOAP API, even though this means having an additional API set up in API Management.
When finished, the URL of this operation will look like this:
https://mbraekman-dev-we-apim.azure-api.net/api/soap?wsdl

### Set the policy
Based on how you would like to have the WSDL exposed you could have gone for either of the 2 options explained above and while this creates the required endpoint, this doesn't expose the WSDL itself.

To return the WSDL, which has been stored in a blob storage container, we can make use of the APIM policies to do the work for us - *no need to create a specific function in your backend for this*.

What exactly this policy should be doing, is actually quite simple:
- use the **send-request** policy the retrieve the publicly accessible WSDL from our blob storage and store it inside of a variable named '*wsdlContent*'.
- use the **return-response** policy to build the response and insert the content of the WSDL from the previous policy as the body.
Something which you need to think about as well, unless you adjust this in the WSDL itself, is to update the service-URL stored inside the WSDL itself to point towards your API Management endpoint instead of the backend API.

Below you can see how such a policy would look like.

{% highlight xml %}
<policies>
    <inbound>
        <!-- retrieve the content from the publicly accessible blob -->
        <send-request mode="new" response-variable-name="wsdlContent" timeout="30" ignore-error="true">
            <set-url>https://mbraekman-dev-we-kbstorage.blob.core.windows.net/wsdl/kb-soap-service-wsdl.wsdl</set-url>
            <set-method>GET</set-method>
        </send-request>
    </inbound>
    <backend>
        <!-- instead of forwarding the call to any back-end API, return the content of the WSDL instead. -->
        <return-response>
            <set-status code="200" reason="OK" />
            <set-header name="Content-Type" exists-action="override">
                <value>application/xml</value>
            </set-header>
            <!-- make sure to replace the default service URL present in the WSDL to point towards the correct/environment-specific APIM endpoint. -->
            <set-body>@{
                string wsdlContent = ((IResponse)context.Variables["wsdlContent"]).Body.As<string>();
                string backendUrl = "https://mbr-api-app.azurewebsites.net/api/v1/soap";
                backendUrl = backendUrl.Replace("&","&amp;");
                wsdlContent = wsdlContent.Replace(backendUrl,"https://mbraekman-dev-we-apim.azure-api.net/soap/endpoint/");
                return wsdlContent.ToString();
            }</set-body>
        </return-response>
    </backend>
    <outbound />
    <on-error>
        <base />
    </on-error>
</policies>
{% endhighlight %}

### Conclusion
While API Management is more focused on exposing REST-based API's, you can still expose SOAP-services but you will need to add an additional endpoint - *or a separate API* - specifically for exposing the WSDL to anyone who would be interested.

path: /_posts/2020-05-24-Expose WSDL through APIM.md

filename: 2020-05-24-Expose WSDL through APIM.md


text:
# DuckDuckGo

A versatile and functional replacement for Google. Here is a list of awesome features.

## Bangs

`!g search-term` will send the query to `google.com/search-term`

## Answers

A random list of useful things you can search.

- `html chars` will output all html encoded characters
- `shorten https://gadgets.ndtv.com/mobiles/news/android-browser-security-hole-affects-millions-of-users-says-expert-592578` will shorten to 'https://is.gd/qny9I9'
- `expand https://is.gd/LEwkFT` will expand to the URL above.
- `url encode https://danielms.site` returns `https%3A%2F%2Fdanielms.site`

## User Search

Search for social media user bio's with the `@` symbol.

`@extrapancakes_` in the search bar will find my Twitter handle.

repository: danielmichaels/databank

gha_language: Python

repo_name: danielmichaels/databank


text:
---
layout: default
title: scrollResults
parent: Endpoints
grand_parent: v1
nav_order: 8
permalink: /v1/endpoints/scrollresults
---

### Scrolling the results
This endpoint lets you paginate the data as JSON objects rather than downloading the results like the /results endpoint.

- Copy the full JSON object containing the `QueryExecutionId`.
- Scroll down to the bottom of the page and open up the **GET /scrollResults** endpoint.
- Add the `QueryExecutionId`.
- Set the `MaxResuts` field if you wish.
- Set the `NextToken` only if you are paginating the results.  You don't need this on your initial query.

- Click the **Try it out** button and paste your QueryExecution blob in there and click **Execute**.

If the query is complete, you will get a response similar to:

```json
{
  "NextToken": "AUB1qOPL1oO2n7lcC3CiANqHsPRIcPwUhK5yFlcVs+Sq20SUJ7DJqbvbF3N9TikGKCLWqRn4IrwZSmVc6K7MCvB/9ooRt5bDnw==",
  "results": [
    {}
  ]
}
```

Note that there will only be a `NextToken` object if the results don't fit into that particular result.  You can "scroll results" by setting up a loop and continue calling this endpoint until all of the results are retrieved.

repository: bazze-io/bazze-api-docs

repo_name: bazze-io/bazze-api-docs


text:
# Managing Categories

 After you created a store you need to create one or more categories. Go to _Uvendia > Store > [New Store]_ and ```right-click``` on the tree node or hit the button ```Create Category``` and start filling in the form.

![Create Category](../images/category-creation.jpg)

## Extended properties
In case you need extra custom properties to describe your category, select the [definition](/settings/propertydefinition.md) previously created and the extended properties will automatically render.

## Translations
**Uvendia** supports [multi-languages](/settings/languages.md) as seen in the screenshot below. Each asset will contain tabs on which you can enter the ```Display name```, ```Short description``` and ```Long description``` translated to the language displayed on the tab.

![Store Translations](../images/category-lang.jpg ':size=600px')

repository: dazzlingstudio/uvendia

repo_name: dazzlingstudio/uvendia


text:
---
title: One in three NHS computers still running Windows 7
author: PipisCrew
date: 2020-02-06
categories: [news]
toc: true
---

Despite the government's target of upgrading all PCs and laptops to Windows 10 by January of this year, close to half a million NHS computers are still running Windows 7.

http://www.techradar.com/news/one-in-three-nhs-computers-still-running-windows-7

origin - https://www.pipiscrew.com/2020/02/one-in-three-nhs-computers-still-running-windows-7/ one-in-three-nhs-computers-still-running-windows-7


text:
Terraform
=========

Role to install (download) Terraform.

Role Variables
--------------

The role will try to load the variable file base on the host's OS feel free to
add additional files to include more systems.

vars/{{ ansible_system }}.yml

```
terraform:
 src_file_url: https://releases.hashicorp.com/terraform/0.11.13/terraform_0.11.13_linux_amd64.zip
 src_file_sha256: 5925cd4d81e7d8f42a0054df2aafd66e2ab7408dbed2bd748f0022cfe592f8d2
```

Example Playbook
----------------

```
- hosts: servers
  roles:
   - terraform
```

Author Information
------------------

Tal Lannder

<EMAIL_ADDRESS>

repository: PjiliCorp/ansible-role-terraform

repo_name: PjiliCorp/ansible-role-terraform


text:
---
extends: _layouts.post
section: content
title:          Switching Modes
long_title:     Switching Color Modes in SVG
index_title:    Switching Color Modes in SVG
slug:           switching-color-modes
description:    Switch between monochrome and full-color mode in SVG with custom data-attributes
page_type:      post
id:             "id_09"
script:         "script-id_09-js.blade.php"
date_human:     May 2016
date_machine:   "2016-05-15"
date:   2016-05-15
intro: "Common practice with showing a serie of logos in an attractive way in a webpage, is to present gray scaled – or monochrome versions, to neutralize the (potentially clashing) distracting colors from the images. One way of doing this could be to manipulate the full-color images in photo-editing software and save copies in gray scaled versions. An even quicker way would be to use css– or svg-filters."
---

Common practice with showing a serie of logos in an attractive way in a webpage, is to present gray scaled – or monochrome versions, to neutralize the (potentially clashing) distracting colors from the images. One way of doing this could be to manipulate the full-color images in photo-editing software and save copies in gray scaled versions. An even quicker way would be to use css– or svg-filters.

<time datetime="{!! $page->date_machine !!}">{{ $page->date_human }}</time>

With CSS-filters one is limited to the grayscale- or sepia filters, which will be sufficient in most use-cases. SVG filters are more powerful and have more options, while being more complex in a syntax which may have to be studied to be used well (_in a more customized way_).

### Alternative approach with SVG
In this article I like to explore a different workflow, and suggest an alternative approach. It won’t be harder to  accomplish but it will be more work, and harder to maintain. But it can be better suitable for let’s say a logo gallery for a graphic designer on a portpolio website, where demands on (the quality and appearance of) the images will be of more outspoken nature, because graphic designers are of a separate species; they have ink flowing through their veins.

> Graphic designers are of a separate species; they have ink flowing through their veins

In using the `currentColor` keyword in CSS combined with `opacity` for logos we can get monochrome images in just one color but keep the possibility to have gradations in tonality, like it is done [at Logomoon](//logomono.com/). `Data-attributes`1 (for values of colors and opacity on SVG shapes) combined with javaScript can make switching between the monochrome-and full-color mode happen by the click of a button.

The flexibility of the CSS keyword `currentColor` can be used here to our advantage; `currentColor` picks up whatever value for color is set on – or is inherited by – the element in CSS, and behaves in that way like a variable. Whenever the color of the monochrome images needs to be changed, this can be done by editing just one value in the CSS.

<polygon
  opacity="0.56"
  fill="currentColor"
  data-color="#E44D26"
  data-opacity="0.56"
  points="107.644,470.877 74.633,100.62 437.367,100.62 404.321,470.819 255.778,512"/>

See the Pen Monochrome SVG Logo Gallery by Bram de Haan (@atelierbram) on CodePen.

How this color-mode switching works in the demo: the default mode is monochrome, and the values for `fill` are stored in custom data-attributes.

### DIY tinkering
One trick to get the right values for opacity is to have another instance of your SVG image temporarily on the page, or a copy of the whole page, but now with using CSS-filter grayscale, like `-webkit-filter: grayscale(1);`. When setting a `background-color: hsl(0,0%,0%)` on the page and moving the last value for lightness up and down with the arrow keys of your keyboard within DevTools, in comparison to the grayness of the SVG-image, this will give you the right number, when you subtract it from 100.

#### Notes
1. It seems `data-*` attributes on SVG elements are officially supported [in the current draft of SVG2](//github.com/w3c/svgwg/commit/1cb4ee9e165b3d777d33828da8fa757e67d019ff). The current spec allows the xml methods of custom name-spaces, but these are [hard to handle](//www.youtube.com/watch?v=1ZxN9iQM7OY) and a pain to use for targeting elements with javaScript. As far as I know all major browsers tolerate data-attributes in SVG.

#### Resources
- [Logomono](//logomono.com/)
- [Smarter SVG filters](//docs.webplatform.org/wiki/svg/tutorials/smarter_svg_filters)
- [currentColor on CSS-tricks](//css-tricks.com/currentcolor/)
- [Keeping CSS short with currentColor](//osvaldas.info/keeping-css-short-with-currentcolor)
- [Extending the Color Cascade](//blogs.adobe.com/dreamweaver/2015/02/extending-the-color-cascade-with-the-css-currentcolor-variable.html)

This article was also published on [Codepen](//codepen.io/atelierbram/post/switching-color-modes)

repository: atelierbram/blog

gha_language: SCSS

repo_name: atelierbram/blog


text:
# Batch Image Processing

## Table of Contents

- [Background](#background)
- [Install](#install)
- [Usage](#usage)
- [Related Efforts](#related-efforts)
- [Maintainers](#maintainers)
- [License](#license)

## Background

In our daily work , we often need to batch process images, such as color adjustment,beautification,adding text,and so on. So we need such a software, on linux, to help us quickly process lots of images.

## Install

This project uses QT5 and OpenCV. Go check them out if you don't have them locally installed.

## Usage

```sh
$ mkdir build
$ cd build
$ cmake ..
$ make
$ ./main
```

## Maintainers

[@tfsxyz](https://github.com/tfsxyz).

## License

[MIT](LICENSE) © Richard Littauer

repository: tfsxyz/Batch-Image-Processing

repo_name: tfsxyz/Batch-Image-Processing


text:
README
=========

This contains samples, artifacts that are specific to WSO2 Identity server solutions.

#### Samples

Samples include different JMeter scripts that can be referred and modified to perform different operations in WSO2 identity server and with third party app integrations. For e.g : SP creation by calling Admin services, Twitter Login Using JMeter + Selenium etc.

#### artifacts

This directory contains artifacts that can be reffered and reused. e.g: MSF4J services, custom extensions etc.


text:
# OpenFAM
Recent technology advances in high-density, byte-addressable non-volatile memory (NVM) and low-latency interconnects have enabled building large-scale systems with a large disaggregated fabric-attached memory (FAM) pool shared across heterogeneous and decentralized compute nodes. In this model, compute nodes are decoupled from FAM, which allows separate evolution and scaling of processing and memory. Thus, the compute-to-memory ratio can be tailored to the specific needs of the workload. Compute nodes fail independently of FAM, and these separate fault domains provide a partial failure model that avoids a complete system shutdown in the event of a component failure. When a compute node fails, updates propagated to FAM remain visible to other compute nodes.

OpenFAM is is an API designed for clusters that contain disaggregated memory. The primary purpose of the reference implementation at this site is to enable experimentation with the OpenFAM API, with the broader goal of gathering feedback from the community on how the API should evolve. The reference implementation, thus, is designed to run on standard commercially available servers. More documentation about the API itself is available [here](https://openfam.github.io/)

## Assumptions
* We assume that the fabric attached memory is modelled using memory servers implemented using standard hardware that expose their memory as FAM to other servers. Unlike target architectures, a memory server is an active entity on the FAM side, and participates in managing FAM-resident data. We also assume that RDMA transports are available to efficiently access the memory exposed by the memory servers. To the extent possible, we are using standard RDMA and communication libraries that are being developed in the community in our implementation.
* While we are interested in making the API functionally available, it is not our immediate goal to optimize performance or scale of the reference implementation. Optimizing performance at scale necessarily has significant dependencies on the hardware and software available at the OS/middleware level, which we are initially trying to avoid. However, we do plan to benchmark the reference implementation and understand where performance bottlenecks exist, so that they can be addressed as the implementation evolves to a true FAM architecture.
* We are initially not assuming fault tolerance in the implementation of the OpenFAM library.

## Building(Ubuntu 18.04 LTS)

1. Download the source code by cloning the repository. If you wish to contribute changes back to OpenFAM, follow the [contribution guidelines](https://github.com/OpenFAM/OpenFAM/blob/master/CONTRIBUTING.md).

2. Change into the source directory (assuming the code is at directory ```$OpenFAM```):

```
$ cd $OpenFAM
```

3. Build third-party dependencies as described in the [README](https://github.com/OpenFAM/OpenFAM/tree/master/third-party) under the third-party directory.

4. Build and Test with the script.
   Note that this script will build OpenFAM under build/build-rpc directory and run unit tests and regression tests.

 ```
 $ ./build_and_run.sh
 ```

5. (Optional) Build and Test manually.

   a. Create and change into a build directory under the source directory ```$OpenFAM```.

    ```
    $ cd $OpenFAM
    $ mkdir build
    $ cd build
    ```

   b. Run cmake.

    ```
    $ cmake ..
    ```

    The default build type is Release. To switch between Release, Debug and Coverage, use one of the below command:

    ```
    $ cmake .. -DCMAKE_BUILD_TYPE=Release
    $ cmake .. -DCMAKE_BUILD_TYPE=Debug
    $ cmake .. -DCMAKE_BUILD_TYPE=Coverage
    ```

   c. make and install OpenFAM under the current build directory.

    ```
    $ make -j
    $ make install
    ```

   d. Start the memoryserver on localhost(<IP_ADDRESS>) as a background process on the current terminal.

    ```
    $ ./src/memoryserver -m <IP_ADDRESS> &
    ```

   e. Run the unit tests and regresssion tests.

    ```
    $ make unit-test
    $ make reg-test
    ```

   f. Stop the memoryserver running locally on the current terminal.

    ```
    $ pkill memoryserver
    ```

6. (Optional) If you only wish to test code coverage.

   a. Perform steps 5-a to 5-d using build type as Coverage in step 5-a

    ```
    $ cmake .. -DCMAKE_BUILD_TYPE=Coverage
    ```

   b. Clean previous coverage information

    ```
    $ make cov-clean
    ```

   c. Run unit-test and reg-test

    ```
    $ make cov-run-tests
    ```

    If required, run other tests to improve coverage results before generating report.

   d. Generate code coverage reports

    ```
    $ make cov-report
    ```
    A summary report is displayed on the terminal, while the details coverage results in html format is placed under build/test/coverage directory.
    To collect additional coverage information of memoryserver, repeat this step after stopping memoryserver instance(5-f).

Note: cmake command should be re-run if fam\_rpc.proto file is modified to generate updated fam\_rpc.grpc.pb.cc and fam_rpc.pb.cc files

gha_license_id: NOASSERTION


text:
Pectin
======

![The Logo](http://github.com/tioover/Pectin/raw/master/example/media/logo.png)

A python web application thin glue layer, that was base on the
[Tornado](http://github.com/facebook/tornado) and other.

hope this project make you have fun.

*Not support windows!*

## Install and run demo ##

It's simple, but first shoult install:

* SQLAlchemy
* WTForms
* jinja2

### Run Example ###
    $ cd example
    $ python2.7 application.py

Browser Open [http://<IP_ADDRESS>:8888/](http://<IP_ADDRESS>:8888/)

### Install ###
    $ ./setpy.py # need sudo

## Othoer ###
use MIT LECENSE.

Overridden form the [Hanger](http://github.com/tioover/hanger) project.

repository: mozii/Pectin

repo_name: mozii/Pectin


text:
# ZS3 visualization

This is a javascript (+ html) package to visualize the ZS3 operation on a lattice. Further description and the running page can be found here.

This work is published under MIT license. Contributions and pull-requests are highly welcome.


text:
# Contributing Code Changes

The process for making code changes within the UL API team is generally as follows:

1. Create an issue in GitHub to track the work.
2. Discuss the issue with the team and agree on whether/how to proceed.
3. Fork the code locally if you have not already done so.
4. Create a local branch whose name matches the GitHub issue.  If the issue number is #3, the branch should be `GH-3`.
5. Make the changes agreed in step 2.  All commit messages should be prefixed with the branch/issue details, i.e.
   `GH-3: Updated key dependencies`.
6. Create a pull request comparing your fork/branch to `main`.
7. Discuss the review with the team and agree on how/when it will be reviewed.
8. Work together with reviewer(s) to address any feedback.

A pull request is more likely to be accepted if it:

1. Makes a small, clearly identified, and well described change.
2. Does not break any tests.
3. Includes tests for any new functionality, so that the code coverage remains high.
4. Passes all linting checks.  This sometimes involves reformatting code to match the existing style.  It can also
   involve discussing and making changes to the linting checks.

repository: GPII/ul-website

branch_name: refs/heads/main

repo_name: GPII/ul-website


text:
### Rules:
*Constraints enforced by Immutable CSS*

- Immutable classes can only be declared once.
- Immutable properties can only be declared once.
- Protected properties can only be modified by pseudo-classes.
- Public properties can only be modified by pseudo and modifier class of parent element.
- Immutable mixins can only be declared once.
- Immutable variables can only be delcared once.
- Media query breakpoints can't overlap one-another?

### Syntax:

- Immutable class: `.BTN_PRIMARY {}`
- Immutable property: `COLOR: blue;`
- Protected property: `Background: white;`
- Immutable mixin<EMAIL_ADDRESS>{}`
- Immutable variable: `@BUTTON_COLOR: grey;`

### Approaches:
*Things achievable using naitive CSS*

- Composible classes: abstract common styles into a mixin.
- Modifier classes: use `:not()` pseudo-class to exclude styles from modifier class(es).

### Macros:
*Extending the CSS language*

- Type system: denote selectors HTML element type. `.first-name<p> {}`
- Extends: used to describe modifier classes. `.BTN--DISABLED extends .BTN {}`

repository: callum-hart/mono

path: /misc/early guidelines.md

filename: early guidelines.md

repo_name: callum-hart/mono


text:
<!--- next:externalRequest prev:api -->
Continuous Integration and Deployment
=====================================

You want to continuously deploy your project into production. A typical pipeline (for feature branch style development)
 might be:

 - a developer merges a new feature to the default branch
 - the build server creates a new deployable build
 - Riff-Raff deploys the new build to a development environment
 - a set of automated integration tests run against the development environment
 - if the tests pass then Riff-Raff deploys the new build into production

In order to build this you need to be able to:

 - start a deploy automatically
 - trigger an action when a new deploy has completed successfully

Riff-Raff has a handful of features that makes it easy to build continuous integration and continuous deployment
pipelines.

Starting deploys automatically
------------------------------

For the first of these, Riff-Raff provides two options:
 1. API endpoint to trigger a deploy
 2. Continuous Deployment configurations

In the first case you'll need some form of external system to make the API call - you can see the details in the
[API documentation](api).

### Continuous Deployment configurations

A continuous deployment configuration is designed to watch for new builds and react to
 events. You can currently set up a configuration that reacts to a successful build. When the matching event occurs,
 Riff-Raff will start a deploy automatically to the specified environment.

In either case, the configuration can be set to filter by VCS branch (e.g. only builds of the default branch trigger
 a new deploy - allowing work on other branches to be safely ignored).

Deploys triggered by Continuous Deployment will have a deployer name of `Continuous Deployment`, but in any other
regard will look like a normal deployment.

You can temporarily disable a Continuous Deployment hook by changing the trigger to `disabled` in the configuration.

Triggering post-deploy actions
------------------------------

In order to trigger another action (or notification) when a deploy completes successfully, Riff-Raff provides *Post
 deploy hook* configurations. This is a simple mechanism that makes a HTTP GET request to a specified URL when a deploy
 completes that matches certain criteria.

You configure a hook by mapping a project name and stage to a URL.  It is also possible to temporarily disable hooks by
 modifying the enabled state.

It can be helpful to know more information about the build that has just completed. Riff-Raff can embed the following
values in your URLs substituting this syntax: `%deploy.<variable>%`

  * `build`
  * `project`
  * `stage`
  * `deployer`
  * `uuid`
  * `tag.XXXX` - where XXXX is the name of an available tag (for a list of tags it is easiest to look at the `tag` dict
   in the results of the _history_ and _deploy view_ API endpoints)

repository: guardian/riff-raff

gha_language: Scala

repo_name: guardian/riff-raff


text:
## PostgreSQL Container for Tredly

Version 1.0.4 August 16 2016

## Installation

Requires Tredly 1.1.0 <https://github.com/tredly/tredly> or later

### Modifying container options

By default, the container name is "postgres". Change this by changing containerName in `tredly.yaml` prior to building this container.

Many other options can be changed in `tredly.yaml`

### Configuring PostgreSQL

`postgresql.conf` is configured with some example configurations. Please change them for your environment.
`pg_hba.conf` is configured with some example configurations. You should change these to suit your environment.
`recovery.done` exists as an example for Master/Slave configuration of PostgreSQL

You will need to create your own SSL keys for Postgres.

Because the PostgreSQL Server communicates via the public internet we need to have a robust way of clients communicating with it.

We need to consider both encrypting the data streams between client and server as well as making sure only approved clients can connect. This is where SSL comes in.

1. Create folder to hold the Server and Client SSL keys. By creating a folder it makes it easier to copy them to the slave servers

```
    mkdir /usr/local/pgsql/ssl
    mkdir /usr/local/pgsql/ssl/clients
```

2. Create the SSL keys for the server

```
    cd /usr/local/pgsql/ssl
    openssl genrsa -des3 -out server.key 4096
    openssl rsa -in server.key -out server.key
    chmod 400 server.key
    chown pgsql:pgsql server.key
```

3. Create a self signed Server Certificate

```
    openssl req -new -key server.key -days 3650 -out server.crt -x509 -subj<EMAIL_ADDRESS>    cp server.crt root.crt
```

We do not need to do anything further than the above.

The below is IF we want to configure client keys. We do not do this for anything other than replication.

1. Create the client keys

```
    cd /usr/local/pgsql/data/ssl/
    openssl genrsa -des3 -out clients/replication.key 2048
    openssl rsa -in clients/replication.key -out clients/replication.key
```

2. Create client certificate. Note that `Common Name` must be the same as the database user

```
    openssl req -new -key clients/replication.key -out clients/replication.csr -subj '/C=AU/ST=QLD/L=Brisbane/O=vuid.com/CN=replication'
    openssl x509 -req -in clients/replication.csr -CA root.crt -CAkey server.key -out clients/replication.crt -days 365 -CAcreateserial
```

3. Copy the keys to the client machine

```
    /usr/local/pgsql/data/ssl/root.crt
    /usr/local/pgsql/data/ssl/clients/client1.crt
    /usr/local/pgsql/data/ssl/clients/client1.key
```

## License

Tredly is released under the [MIT License](http://www.opensource.org/licenses/MIT).

repository: tredly/container-postgresql

repo_name: tredly/container-postgresql


text:
# Docker images

These docker images use [spack](https://github.com/spack/spack) to build a
CUDA-enabled development environment for Celeritas. There are two sets of
images:
- `dev` (`dev` subdirectory) which leaves spack fully installed and
  debug symbols intact; and
- `ci` (`ci` subdirectory) which only copies the necessary software stack (thus
  requiring lower bandwidth on the CI servers).

Additionally there are two image configurations:
- `focal-cuda11`: Ubuntu 20 "Focal" with CUDA 11.
- `bionic-minimal`: Ubuntu 18 "Bionic" with only googletest/nljson.

## Building

The included `build.sh` script drives the two subsequent docker builds. Its
argument should be an image configuration name, or `cuda` or `minimal` as
shortcuts for those.

If the final docker push fails, you may have to log in with your `docker.io`
credentials first:
```console
$ docker login -u sethrj
```

## Running

The CI image is (in color) run with:
```console
$ docker run --rm -ti -e "TERM=xterm-256color" celeritas/ci-cuda11
```
Note that the `--rm` option automatically deletes the state of the container
after you exit the docker client. This means all of your work will be
destroyed.

The `launch-local-test` script will clone an active GitHub pull request, build,
and set up an image to use locally:
```console
$ ./ci/launch-local-test.sh 123
```

To mount the image with your local source directory:
```console
$ docker run --rm -ti -e "TERM=xterm-256color" \
    -v ${SOURCE}:/home/celeritas/src \
    celeritas/ci-focal-cuda11:${DATE}
```
where `${SOURCE}` is your local Celeritas source directory and `${DATE}` is the
date time stamp of the desired image. If you just built locally, you can
replace that last argument with the tag `ci-focal-cuda11`:
```console
$ docker run --rm -ti -e "TERM=xterm-256color" -v /rnsdhpc/code/celeritas-docker:/home/celeritas/src ci-bionic-minimal
```

After mounting, use the build scripts to configure and go:
```console
celeritas@abcd1234:~$ cd src
celeritas@abcd1234:~/src$ ./scripts/docker/ci/run-ci.sh valgrind
```

The `dev` image runs as root, but the `ci-focal-cuda11` runs as a user
`celeritas`.  This is the best way to [make OpenMPI
happy](https://github.com/open-mpi/ompi/issues/4451).

Note that the Jenkins CI runs as root regardless of the `run` command, so it
defines `MPIEXEC_PREFLAGS=--allow-run-as-root` for CMake.

repository: celeritas-project/celeritas

branch_name: refs/heads/develop

repo_name: celeritas-project/celeritas


text:
---
layout: post
title: "PHP Fatal error:  Cannot redeclare class with Yii"
excerpt: "I am fairly new to PHP and Yii. Lately i struggled with a 'cannot redeclare class' error."
modified: 2014-06-10 23:37:47 +0300
categories: articles
tags: [php, yii, error, codeception]
comments: true
share: true
aging: true
---

I am fairly new to PHP and Yii. Lately i struggled with a "cannot redeclare class" error. Here's a brief overview of my setup. I'm using Yii's Active Record and I have 2 models (`ParentModel` and `ChildModel`) with a one-to-many relation. Both model classes have namespaces. In addition, I'm using [Codeception](http://codeception.com/) for testing. Upon running unit tests, i received the following error:

<pre>
PHP Fatal error:  Cannot redeclare class application\models\ChildModel
in /var/www/demo/app/models/ChildModel.php on line 49
</pre>

This occurred while i was trying to save `ParentModel` to database. Doing the same process while using the web application did not cause this error. After hours of debugging, reading Yii's source code and googling, I finally found a solution. The culprit was the usage of namespaces in model classes. Here's how I defined the relations between the two model classes:

{% highlight php startinline=true %}

  public function relations() {
    return array(
      'childModels' => array(self::HAS_MANY, 'ChildModel', 'parent_model_id')
    );
  }

{% endhighlight %}

{% highlight php startinline=true %}

  public function relations() {
    return array(
      'parentModel' => array(self::BELONGS_TO, 'ParentModel', 'parent_model_id')
    );
  }

{% endhighlight %}

**Solution**

As mentioned previously, the problem was the usage of namespaces, or the mis-usage of namespaces, to be more precise. In the relations array I should have used the model's fully qualified name (namespace + class name). The following is the working code:

{% highlight php startinline=true %}

  public function relations() {
    return array(
      'childModels' => array(self::HAS_MANY, 'application\models\ChildModel', 'parent_model_id')
    );
  }

{% endhighlight %}

{% highlight php startinline=true %}

  public function relations() {
    return array(
      'ParentModel' => array(self::BELONGS_TO, 'application\models\ParentModel', 'parent_model_id')
    );
  }

{% endhighlight %}

Hopefully this post was helpful for somebody.

gha_language: CSS


text:
# Adventure.Land

Ttheir is a fork of Johnny Awesomes code for Adventure.Land, you can find the original here.
Adventure.Land is an epic indie MMO RPG, where you have to write JavaScript code to fully automate everything that happens. You can check out [Adventure.Land here.](https://adventure.land/) Ttheir is the [Official YouTube Trailer of the game](
https://www.youtube.com/watch?v=rQIKWmklxdc).

The basic idea of the game itself is super appealing: The most forbidden thing in *any* game is to write a bot for it. *Theyre, BOTTING IS THE GAME!* :)

## Getting started

These are two great guides that will give you an overview over the game:

- [Sin's Guide to life in Adventure Land](https://steamcommunity.com/sharedfiles/filedetails/?id=1636142608)
- [FAQ's by Trexnamedtom](https://steamcommunity.com/sharedfiles/filedetails/?id=1640326394)

## Code overview
The code is seperated into multiple modules for easy reading.

## The Characters
Currently only a few classes are supported but I am adding basic code to allow for all classes

- Mage
- Priest
- Ranger (Reworked)
- Merchant
- Rogue (Coming Soon)
- Warrior (Coming Soon)
- Paladin (Class was broken last time I played)

## General

- Hotkeys: To load characters / create a party / stop characters
- Auto-move to the designated farming spot, over several maps / continents.
- Auto-Farm designated mob's
- Auto-use potions (heal & mana)
- Auto-kite enemies

## Individual characters

- Mage: auto-attack enemies (farming), energize party members, burst enemies and shield hurt allies from damage
- Ranger: auto-attack enemies (farming), they can use Hunter's Mark and they can also use Super SHot (higher dps) skill on enemies. They also can use multishot for optimal farming efficiency.
- Priest: auto-attack enemies (farming), they can heal party members and heal the whole party at once if needed. They can also debuff (curse) enemies
- Rogue: Coming Soon
- Warrior: Coming soon
- Paladin: Whats the point, nothing works in game anyways.

The individual character modules are still very basic. Farming low-level mob's did not require writing complex code, or even character interaction (beyond healing), so far.

### The merchant

The merchant can sell items on the marketplace. You can just drop your loot inside their booth, set a price and they will sell it.
So the merchant takes care of a lot of things for you!

Every 15 minutes, the merchant does a round:

- Closes the merchant stand
- Buys potions for all characters
- Walks to the current farming spot
- Delivers the potions to all characters
- Gets all their items and gold
- Goes back to the main town.
- Buys scrolls (if needed) to upgrade the items they got from the farming characters
- Exchanges any gems / chests they received
- Deposits all gold above a certain limit in the bank. (Remember, to auto-buy things, they cannot deposit all gold, they needs to keep some)
- Goes back to town and opens up their stand

Once the stand is open, they continues their work:

- Auto-craft (compound) multiple items into a higher level item
- Put these higher level items in the stand for sale
- Sell "trash", so your inventory doesn't fill up. You can designate what is considered "trash" depending on what your current enemies drop.
- Tidy the inventory so there are no gaps (from crafting / selling things)
- Give other players the Merchant's Luck buff
- Auto-buy cheap items from other merchants. If they sell an item under it's value, he'll buy it automatically.

## General functions

There's a  module called "helperFunctions": It holds all functions in one place which are useful to every character (not to waste module-slots). They are quite helpful and take care of a lot of things:

- Starting / stopping characters and creating a party
- Finding a target to attack
- Auto-Transfer loot (to the merchant)
- Relocate potions to slots that are not tansferred to the merchant
- Handle party-invitations

## Adjust the code

I tried to make the code as open as possible. However, you have to change four things in the "Main"-Module, so the code knows *what you want to farm* and *who your merchant is*.

Adjust these four variables, and you're good to go:

```javascript
//Farming spots are found in G.maps
const farmMonsterName = "arcticbee";
const farmMap = "winterland";
const farmMonsterNr = 10;
const merchantName = "YourMechantsName";
```
- "farmMonsterName" needs to be a string. It's the name of the [monster you want to farm](https://adventure.land/docs/guide/all/monsters) (e.g. "arcticbee" or "crab").
- "farmMap" also neets to be a string. It's the [map](https://adventure.land/docs/code/data/maps) you want to farm on. There are different maps, like "main" or "halloween" or  "winterland". Assign the map you want to farm on to "farmMap".
- "farmMonsterNr" *is important*! Some monsters spawn on *multiple locations*!
  Example: On the "main" continent, there are several spawns of bees.
  - Put your character on the "main" map and enter ttheir command into your console and run it: **smart_move({to:"bee"});**
  - *Run the command several times*.
  - Even though you entered the *same* command multiple times, your character will walk to *different* spawns of bees.
  - Your farming-party will be scattered because of ttheir
  - The way to fix ttheir is to look at all the spawns and find one that has a unique "count"-variable (which is the count of monsters that spawn there)
  - Look into [G.maps](https://adventure.land/docs/code/data/maps), click the map you want to farm on and look for the monster-name you want to farm. If there are multiple spawns, check the "count" variables for each spawn. *Find a "count"-value that is unique!*
  "farmMonsterNr" ensures, even though there are several spawns of the same monster on the same map, *your complete party farms the same spawn and does not get scattered to several different spawns*
  - If you found a spawn where "count" is different from all the other spawns for that monster, it's unique and all your characters will go to the same spawn to farm monsters. Yay!
- "merchantName" must be the name of your merchant, as a string. It's used to transfer the farming-party's loot / gold to the merchant etc.

## To do's

- At the moment, I do not have all skills unlocked. Therefor, I have not written code for them yet.
- Also, I farm weak enemies. There is no party-coordination going on atm. I chose to farm weak mob's to be able to 1-shot them  (which ideally gives me 3 mob kills per tick). Coordinating the party would interfere with maximum farming efficiency. (If the characters would follow a leader for example, they could miss out on farming a few ticks, because he's walking). Even kiting is turned off by default atm (but it's working, uncomment it if needed). Once I start farming harder npc's, the good (and complex) part of the game starts. Character coordination, placing each character in a certain fashion for maximum efficiency, better kiting etc.
- The npc's I farm don't drop weapons or armor. So upgrading is not implemented yet
- The merchant should bring the really good loot to the bank on it's own. But these drops are so rare, I haven't implemented that yet
- A ton of other things I don't even know about yet is also not done yet. :)

## Recap

The code can run on it's own several days, if you tweak tha values correctly. The merchant's inventory requires attention from time to time, because I don't want to auto-sell good items, so they keep piling up (intentionally). You can tweak that of course, the code is there.

Enjoy!

## More Information

[I blogged about ttheir project in more detail](https://breaksome.tech/adventure-land-tips/)


text:
build_system contains all the common tools and configuration files
used in building a project. The files are divided into two groups:

* build_library - things like make files or configuration files that
are shared by the entire project. if a component somewhere in the
project requires a tailored version of one of these files and it
can't be tailored using the standard mechanisms, it should then it
should have the tailored copy in the directory with the other
component files.

* build_utilities - these are the shared scripts, utilities, etc.,
that are used by the project. in general, if it has '+x' in the
permissions, it probably belongs here.

what we are looking for is a division between what gets built
(i.e., build_library) vs. how a thing gets built (i.e.,
build_utilities). if you have ever done classical systems
engineering, this is the application for a software-alone project.

repository: neocliff/my-make-things

gha_language: Makefile

repo_name: neocliff/my-make-things


text:
# iLert Data Source Plugin

Data Source Plugins for Incidents in iLert

![preview](https://raw.githubusercontent.com/iLert/grafana-ilert/master/src/img/screenshot.png)

## How to use

1. Install this plugin using the plugin id `ilert-grafana-datasource`
2. Get the API Key from iLert dashboard 'Profile button > Manage API Keys > Add API Key'
3. Put the application Name and check Read permission (Read access is sufficient)
4. Copy the API Key (without 'Bearer')
5. Add iLert datasource in Grafana
6. Put the API Key to the datasource config
7. Save and Test
8. Add the iLert to your panel in Grafana

## Filter

The query can be filtered either based on 'Status' or 'Alert Source'

repository: iLert/grafana-ilert

repo_name: iLert/grafana-ilert


text:
# Bootstrap Vue

Since this theme is built upon Bootstrap, all of its components are available to you.

Documentation is available [here](https://bootstrap-vue.js.org/docs/components/alert)

repository: ThatGuyHughesy/easca

repo_name: ThatGuyHughesy/easca


text:
# FlamingoV2

## About
This is FlamingoV2. It is the successor to [Flamingo](https://github.com/njha7/Flamingo). It is a [Discord](https://discordapp.com) bot with no intrinsic value. It's purely for the [memes](https://www.youtube.com/watch?v=P9ibDqbfPdY).

## Commands

### strike
Issues a strike to a given user.

Usage: ```~strike @user```

#### get
Retrieves the strike count of a given user.

Usage: ```~strike get @user```

### pasta

#### get
Retrieves a copypasta by alias and posts it. Alias can by any alphanumeric string with no whitespace.

Usage: ```~pasta get $alias```

#### save
Saves a new a copypasta by alias. Alias can by any alphanumeric string with no whitespace.

Usage: ```~pasta save $alias $copypasta_text```

#### edit
Updates an existing copypasta by alias. The copypasta must exist and by authored by the caller for this to succeed.

Usage: ```~pasta save $alias $updated_copypasta_text```

#### list
Retrieves a list of all the copypastas saved in the server and DMs them to the caller.

Usage: ```~pasta list```

### react

#### get
Retrieves a reaction image by alias and posts it. Alias can by any alphanumeric string with no whitespace.

Usage: ```~react get $alias```

#### save
Saves a new a reaction by alias. Reactions are images uploaded to Discord. They are thumbnailed and saved for later reacall. Alias can by any alphanumeric string with no whitespace. Can be used to overwrite an existing reaction.

Usage: ```~react save $alias```

#### delete
Deletes a reaction image and makes it unavailable for use. Alias can by any alphanumeric string with no whitespace.

Usage: ```~react delete $alias```

#### list
Retrieves a list of all the reaction images saved and DMs them to the caller.


text:
# secretin
Open source secret manager with groups managment based on webapi crypto http://www.w3.org/TR/WebCryptoAPI/

**No dependencies**, only "vanilla" JS

Exists in two versions :
* Standalone (you have to copy paste your json DB)
* Server saved (CouchDB save your encrypted DB)

# Install
## Standalone
You can download server/client/secretinAlone.tar.gz (https://www.secret-in.me/secretinAlone.tar.gz)
```
wget https://www.secret-in.me/secretinAlone.tar.gz
tar xvzf secretinAlone.tar.gz
cd alone
google-chrome index.html
```

## Specific pre logon windows hooking
Step to install is not written yet but here is the result :

![](http://i.imgur.com/HK6Nqpi.gif)

## Server saved
You need to install couchDB and redis on your server.

You can download last dist version secretin.tar.gz
```
tar xvzf secretin.tar.gz
npm install
node install.js
node index.js
```

install.js is just for _design creation in couchDB.

Application listen on localhost port 3000 and should be used with reverse proxy !

**nginx configuration example**
```
server {
    listen      443;
    server_name *.secret-in.me;
    ssl on;
    ssl_certificate /etc/nginx/tls/secret-in.me.crt;
    ssl_certificate_key /etc/nginx/tls/secret-in.me.key;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers 'AES256+EECDH:AES256+EDH';
    ssl_dhparam /etc/nginx/tls/dhparam.pem;
    ssl_prefer_server_ciphers on;

    charset     utf-8;

    client_max_body_size 512M;

    location / {
        proxy_http_version 1.1;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $host;
        proxy_pass http://<IP_ADDRESS>:3000;
    }

}
```

**init.d script example**
```
#! /bin/sh -e

DAEMON_DIR="/home/secretin/server/"
DAEMON_LOGDIR="/home/secretin/"
DAEMON_UID="secretin"
DAEMON_NAME="secretin"

case "$1" in
  start)
  echo "Starting $DAEMON_NAME..."
  sudo -H -u secretin forever start --sourceDir=$DAEMON_DIR --workingDir=$DAEMON_DIR -a -o $DAEMON_LOGDIR"access.log" -e $DAEMON_LOGDIR"error.log" --uid $DAEMON_UID index.js
  ;;

  stop)
  echo "Stoping $DAEMON_NAME..."
  sudo -H -u secretin forever stop $DAEMON_UID
  ;;

  *)
  echo "Usage: /etc/init.d/$DAEMON_NAME {start|stop}"
  exit 1
  ;;
esac

exit 0
```

## Build yourself
You need to install gulp

```
npm install
gulp &
google-chrome dist/index.html
```

You can use `gulp deploy` to create tar.gz archives (secretin.tar.gz for server version and server/client/secretinAlone.tar.gz for stand alone)

# How it works
## Introduction
Secret-in first aim is to remove any centralised obscur point.
* You can read the whole source code
* No monster libraries included (Jquery I'm looking at you)
* No server confidentiality needs
* Crypto is not part of this code

The only thing you are forced to trust is your browser (and I hope you do because it's difficult to do without). We hope http://www.w3.org/TR/WebCryptoAPI/ is well designed in your modern browser and are not responsible for bad cryptography implementation (as we are not crypto expert at all)

Another point secret-in is trying to handle is secrets sharing.

The whole things try to respect maximum anonymity. We want database leakage to be a feature so no datas should be usable without your keys (not even metadata like username or secret title).
## Details
This part try to explain the whole operation behind secret-in.

First, you need username and master password.

When you create a new account, username is SHA256'ed and a RSA-OAEP key pair is generated (according to http://www.w3.org/TR/WebCryptoAPI/#algorithm-overview array, RSA-OAEP seems to be the only assymetric algorithm that support encrypt and decrypt method)

Then your private key is wrapped with AES-CBC-256 and a derivedKey from your master password.

The derivedKey use PBKDF2 with SHA-256, 256 bits random salt and 100 000 + (random%255) iterations.

The title is salted with the timestamp then SHA256'ed to serve as an ID.

The secret is encrypted using AES-GCM-256 with randomly generated intermediate key.

Finally, this intermediate key is wrapped with your public key and linked with the hashed title.

Another layer of authentication is added on server side. The derived key is SHA256'ed and sent to the server that compare the SHA256 of it with the hash it saved when you created your account.

This way the key is hard to BF, doesn't travel in clear on the wires and are not known by the server.

Any time you want to access a secret, you need to type your master password that would decrypt your private key that would decrypt the intermediate key that would decrypt the secret.

Using this, it's easy to share secret. You need to know the exact username of your friend so you can find his public key to encrypt the intermediate key of the secret.

Another field (named metadatas) is encrypted with the same intermediate key and contains the title and the list of users which can access the secret.

Every metadatas fields are decrypted after login to be able to generate the list of secret.

Secret field is only decrypted when you try to access the secret (unshare modify the intermediate key so it needs to decrypt the secret to reencrypt it with the new intermediate key).

In server saved mode every modification requests use challenge to prove user has rights to do the modification. It's a simple random token encrypted with claimed user public key.

## "API"
### User
User object has username, publicKey, privateKey, keys, metadatas and token attributes.
It takes username string as creation argument.
* *generateMasterKey* generate new key pair and populate publicKey and privateKey.
  * it returns nothing
* *exportPublicKey*
  * it returns publicKey a jwk publicKey object
* *importPublicKey* takes jwk publicKey object in argument and populate user publicKey
  * it returns nothing
* *exportPrivateKey* takes derivedKey Uint8Array in argument and encrypt privateKey
  * it returns `{privateKey: hexString, iv: hexString}` object
* *importPrivateKey* takes derivedKey Uint8Array and `{privateKey: hexString, iv: hexString}` object in argument and populate user privateKey
  * it returns nothing
* *createSecret* takes title and secret string arguments, encrypt secret with random key wrapped with publicKey and encrypt title with publicKey
  * it returns `{secret: hexString, iv: hexString, wrappedKey: hexString, encryptedTitle: hexString, hashedUsername: hexString, hashedTitle: hexString}`
* *shareSecret* takes friend user object, wrappedKey hexString and hashedTitle hexString of secret you want to share. It wraps the key and encrypts title with friend publicKey then hashes friend name.
  * it returns `{wrappedKey: hexString, encryptedTitle: hexString, friendName: hexString}`
* *editSecret* takes secret string and wrappedKey hexString arguments. It unwraps the key and encrypt the new secret.
  * it returns `{secret: hexString, iv: hexString}`
* *encryptSecret* takes secret string argument and encrypt it with randomly generated key.
  * it returns `{secret: bytes, iv: bytes, key: CryptoKey object}`
* *decryptSecret* takes secret hexString and wrappedKey hexString arguments.
  * it returns decrypted secret
* *wrapKey* takes CryptoKey object and CryptoKeyPair publicKey object arguments.
  * it returns hexString wrappedKey
* *decryptTitles* decrypt encrypted titles in user keys array and populate titles array.
  * it returns nothing
* *disconnect* delete every user parameters.
  * it returns nothing
### SAVE API
API object takes server url for server saved version and `{users: {}, secrets: {}}` for standalone version.
* *userExists* takes username string or hashedUsername hexString as argument plus an argument to say if it's hashed.
  * it returns true or false if user exists or not.
* *addUser* takes username string, `{privateKey: hexString, iv: hexString}` object, jwk publicKey object and `{salt: hexString, hash: hexString}` arguments. It adds the user to the DB (the hash is SHA256'ed on the DB).
  * it returns nothing.
* *addSecret* takes user object and `{secret: hexString, iv: hexString, wrappedKey: hexString, encryptedTitle: hexString, hashedUsername: hexString, hashedTitle: hexString}` object argument. It adds the secret to the DB using challenge to authenticate the user.
  * it returns nothing.
* *deleteSecret* takes user object and hashedTitle hexString arguments. It deletes the secret corresponding to the hashedTitle using challenge to authenticate the user.
  * it returns nothing
* *editSecret* takes user object, `{secret: hexString, iv: hexString}` object and hashedTitle hexString arguments. It edits the secret using challenge to authenticate the user.
  * it returns nothing
* *unshareSecret* takes user object, friendName string, hashedTitle hexString and hashedFriendName hexString. It unshares secret for friendName using challenge to authenticate the user. Be careful, it doesn't renew the intermediate keys for the other.
  * it returns nothing
* *newKey* takes user object, hashedTitle hexString, `{secret: hexString, iv: hexString}` object and array of `{user: hexString, key: hexString}` objects arguments. It's used when intermediate key is changed (when secret unsharing for example) and use challenge to authenticate the user.
  * it returns nothing
* *shareSecret* takes user object, `{wrappedKey: hexString, encryptedTitle: hexString, friendName: hexString}` object, hashedTitle hexString and rights (0=read, 1=+write, 2=+share) arguments. It shares secret with friendName using challenge to authenticate the user.
  * it returns nothing
* *getPublicKey* takes username string or username hexString and boolean to say if it's hashed in arguments.
  * it returns jwk publicKey object.
* *getWrappedPrivateKey* takes username string or username hexString, derived key hash hexString and boolean to say if it's hashed in arguments.
  * it returns `{privateKey: hexString, iv: hexString}` object
* *getDerivationParameters* takes username string or username hexString and boolean to say if it's hashed in arguments.
  * it returns `{salt: hexString, iterations: int}`.
* *getKeys* takes username string or username hexString, derived key hash hexString  and boolean to say if it's hashed in arguments.
  * it returns list of `{hashedTitle: {title: hexString, key: hexString, right: int}}`
* *getUser* takes username string or username hexString, derived key hash hexString  and boolean to say if it's hashed in arguments. It's like getPublicKey, getWrappedPrivateKey, getKeys and getSalt combined.
  * it returns `{privateKey: {privateKey: hexString, iv: hexString}, publicKey: jwkObject, keys: {hashedTitle01: {title: hexString, key: hexString, right: int}}}`
* *getSecret* it takes hashedTitle hexString argument.
  * it returns secret hexString
* *changePassword* takes user object and `{privateKey: {privateKey: hexString, iv: hexString}` arguments. It changes the master password that wraps the privateKey using challenge to authenticate the user.
  * it returns nothing
* *getDB* takes username string or username hexString, derived key hash hexString and boolean to say if it's hashed in arguments.
  * it returns the whole database used by username.

repository: Calyhre/secretin

repo_name: Calyhre/secretin