Results for git-push-server

Use git to push and pull from ftp servers

Easily deploy your application to your own server using "git push"

Itegrate Git with your Mingle project by posting murmurs to your Mingle project when new commits got pushed to Git server. This gem provides command to generate Git post-receive hook and post murmurs to your Mingle project.

Gift provides a simple interface for pushing your site to a server that does not support git, via FTP.

Quickly copy files (e.g. YMLs or configuration files) to multiple EngineYard servers

Quickly copy files (e.g. YMLs or configuration files) to multiple EngineYard servers

Remote syslog appender for Logging

== Jiveapps These tools are all about making Jive App development as easy as possible. After you install the tools, it only takes a single command to: 1. Create a new app - a simple Hello World application. 2. Set up version control for your code using Git. 3. Host the app code online at Jive's AppHosting server. 4. Register the app on the Jive Apps Marketplace as an app "in development". 5. Install the app on your default app dashboard in the Jive Apps Sandbox. After you install, use this simple workflow to make changes and see them reflected in the sandbox: 1. Make a change to the code on your local machine. 2. Commit the changes to your local Git repository. 3. Push the changes to the remote Jive Apps repository. This automatically updates the hosted copy on the Jive AppHosting server. 4. Refresh the app dashboard or canvas page on the Jive Apps Sandbox and see your changes. Other features: * LiveDev: preview your changes on the Jive App Sandbox in real time * Collaboration: add other developers to your project * OAuth Key Management: associate consumer key/secret pairs with service names for use in your apps

# CheckChefConverge This is a Nagios/Sensu check that can check if nodes returned from a chef search have converged recently. ## Installation Add this line to your application's Gemfile: ```ruby gem 'check_chef_converge' ``` And then execute: $ bundle Or install it yourself as: $ gem install check_chef_converge ## Usage ``` Usage: check_chef_converge -w, --warn-minutes MINUTES Warning when chef has not converged in minutes.Default 65 -c, --crit-minutes MINUTES Critical when chef has not converged in minutes.Default 70 -q, --query SEARCH Chef query to filter on. Default 'fqdn:travis-work-mbp.local' --chef-client-config CONFIG Chef client configuration. --chef-server-url URL Chef Server URL. Must pass client-name and client-key or client-key-file with this option. --chef-client-name NAME Chef Client Name. Only used with server-url --chef-client-key KEY Chef Client Key (string). Only used with server-url. Takes precedence over client-key-file. --chef-client-key-file PATH Chef Client Key File. Only used with server-url -h, --help Show this message --version Show version ``` ## Development After checking out the repo, run `bin/setup` to install dependencies. Then, run `rake spec` to run the tests. You can also run `bin/console` for an interactive prompt that will allow you to experiment. To install this gem onto your local machine, run `bundle exec rake install`. To release a new version, update the version number in `version.rb`, and then run `bundle exec rake release`, which will create a git tag for the version, push git commits and tags, and push the `.gem` file to [rubygems.org](https://rubygems.org). ## Contributing Bug reports and pull requests are welcome on GitHub at https://github.com/Altiscale/check_chef_converge. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the [Contributor Covenant](contributor-covenant.org) code of conduct.

# SshSig - SSH signature verification in pure ruby SshSig is a Ruby gem which can be used to verify signatures signed created by `ssh-keygen`. This capability was [first added](https://github.com/openssh/openssh-portable/commit/2a9c9f7272c1e8665155118fe6536bebdafb6166) in OpenSSH 8.0 allows SSH keys to be used for GPG-like signing capabilities, [including signing git commits](https://github.com/git/git/pull/1041). ## Installation Add this line to your application's Gemfile: ```ruby gem 'ssh_sig' ``` And then execute: $ bundle install Or install it yourself as: $ gem install ssh_sig ## Usage Version 1 of [the SSH signature format](https://github.com/openssh/openssh-portable/blob/b7ffbb17e37f59249c31f1ff59d6c5d80888f689/PROTOCOL.sshsig) supports `ed25519` and `rsa` keys. It is recommended that you use `ed25519` over `rsa` where possible (`ssh-keygen -t ed25519`). In order to verify a signature you need: 1. The public key of the sender 1. The signature file 1. The message to be verified. ```ruby require 'ssh_sig' armored_pubkey = "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILXPkJPI4TMFWZP4xRBQjNeizUG99KuZCt9G23rX48kz" blob = ::SshSig::Blob.from_armor( <<~EOF -----BEGIN SSH SIGNATURE----- U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgtc+Qk8jhMwVZk/jFEFCM16LNQb 30q5kK30bbetfjyTMAAAAEZmlsZQAAAAAAAAAGc2hhNTEyAAAAUwAAAAtzc2gtZWQyNTUx OQAAAECJITeYJIlEeydsCTh1DkfdhlDJFBa73ojfWe0MbrIzoJKd9THd9WeQrhygSRGsNG cU/stk3/919nykg67yG2gN -----END SSH SIGNATURE----- EOF ) message = "This message was definitely sent by Brian Williams" valid = ::SshSig::Verifier .from_armored_pubkey(armored_pubkey) .verify(blob, message) if valid puts 'Signature is valid' else puts 'Signature is not valid' end ``` Signatures can be created using `ssh-keygen -Y sign -n file -f ~/.ssh/ed_25519 message.txt` and will be outputted in `message.txt.sig`. Public keys can be found in a variety of places, including: - Your `~/.ssh/id_<alg>.pub` file - `authorized_keys` files on servers - `https://gitlab.com/<username>.keys` - `https://github.com/<username>.keys` The `SshSig::Verifier#from_gitlab` and `SshSig::Verifier#from_github` methods are provided to automatically load public keys from the respective `<username>.keys` urls. ```ruby require 'ssh_sig' blob = ::SshSig::Blob.from_armor( <<~EOF -----BEGIN SSH SIGNATURE----- U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgtc+Qk8jhMwVZk/jFEFCM16LNQb 30q5kK30bbetfjyTMAAAAEZmlsZQAAAAAAAAAGc2hhNTEyAAAAUwAAAAtzc2gtZWQyNTUx OQAAAECJITeYJIlEeydsCTh1DkfdhlDJFBa73ojfWe0MbrIzoJKd9THd9WeQrhygSRGsNG cU/stk3/919nykg67yG2gN -----END SSH SIGNATURE----- EOF ) message = 'This message was definitely sent by Brian Williams' valid = ::SshSig::Verifier .from_gitlab('bwill') .verify(blob, message) if valid puts 'Signature is valid' else puts 'Signature is not valid' end ``` ## Is it safe to re-purpose SSH keys for signing? Yes. The [SSH signature protocol](https://github.com/openssh/openssh-portable/blob/d575cf44895104e0fcb0629920fb645207218129/PROTOCOL.sshsig) is designed to be resistant to cross-protocol attacks, where signatures created for one purpose (i.e. signing a git commit), may be re-used for another purpose (i.e. authenticating to a server). It does this using the magic pre-amble (to differentiate between messages signed by `ssh-keygen` and messages used for SSH authentication) and namespaces (to differentiate between messages signed by `ssh-keygen` but used for different purposes). This causes identical messages to produce different signatures for each different protocol. ## Development After checking out the repo, run `bin/setup` to install dependencies. Then, run `rake spec` to run the tests. You can also run `bin/console` for an interactive prompt that will allow you to experiment. To install this gem onto your local machine, run `bundle exec rake install`. To release a new version, update the version number in `version.rb`, and then run `bundle exec rake release`, which will create a git tag for the version, push git commits and the created tag, and push the `.gem` file to [rubygems.org](https://rubygems.org). ## Contributing Bug reports and pull requests are welcome on GitHub at https://github.com/[USERNAME]/ssh_sig. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the [code of conduct](https://github.com/[USERNAME]/ssh_sig/blob/main/CODE_OF_CONDUCT.md). ## License The gem is available as open source under the terms of the [MIT License](https://opensource.org/licenses/MIT).

OVH::Provisioner ================ Interact with OVH REST API, mainly targeted to manage dedicated servers and OVH DNS. Installation ------------ Add this line to your application's Gemfile: ```ruby gem 'ovh-provisioner' ``` And then execute: $ bundle Or install it yourself as: $ gem install ovh-provisioner Configuration ------------- The best way to use ovh-provisioner is to create a configuration file (recommended path: ~/.config/ovh-provisioner.yml) containing your keys and some general configuration. Then, just launch it to get all commands with their description. Example: ```yaml # All keys can be overriden with cli options api_url: https://eu.api.ovh.com/1.0 app_key: XXXXXXXXXXXX app_secret: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX consumer_key: XXXXXXXXXXXXXXXXXXXXXXXXXXXX template: template_name # is be defined in OVH manager when you save a template use_distrib_kernel: true ssh-key: 'key_name_to install' # name_scheme support any variable available as attribute in # lib/ovh/provisioner/api_object/dedicated_server.rb # Along with name_domain, it is used to rename (reverse dns) servers name_scheme: '%{location}-%{flavor_tag}-%{server_id}.%{vrack}' name_domain: example.com # example of flavors, you can use any hardware parameters from # GET /dedicated/server/{serviceName}/specifications/hardware # to differentiate your flavors flavors: EG-16S: tag: eg16s hardware: description: 'Serveur EG-16 - E3-1230v6 - 16GB - SoftRaid 2x450GB NVMe' EG-32S: tag: eg32s hardware: description: 'Serveur EG-32 - E3-1270v6 - 32GB - SoftRaid 2x450GB NVMe' EG-64S: tag: eg64s hardware: description: 'Serveur EG-64 - E5-1650v3 - 64GB - SoftRaid 2x450GB NVMe' ``` Development ----------- After checking out the repo, run `bin/setup` to install dependencies. Then, run `rake spec` to run the tests. You can also run `bin/console` for an interactive prompt that will allow you to experiment. To install this gem onto your local machine, run `bundle exec rake install`. To release a new version, update the version number in `version.rb`, and then run `bundle exec rake release`, which will create a git tag for the version, push git commits and tags, and push the `.gem` file to [rubygems.org](https://rubygems.org). Contributing ------------ Please read carefully [CONTRIBUTING.md](CONTRIBUTING.md) before making a merge request. License and Author ------------------ - Author:: Samuel Bernard (<samuel.bernard@gmail.com>) ```text Copyright (c) 2015-2016 Sam4Mobile, 2017-2018 Make.org Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. ```

== README.md: #ScheduledResource This gem is for displaying how things are used over time -- a schedule for a set of "resources". You can configure the elements of the schedule and there are utilities and protocols to connect them: - Configuration (specification and management), - Query interfaces (a REST-like API and internal protocols to query the models), and - A basic Rails controller implementation. We have a way to configure the schedule, internal methods to generate the data, and a way to retrieve data from the client. However this gem is largely view-framework agnostic. We could use a variety of client-side packages or even more traditional Rails view templates to generate HTML. In any case, to get a good feel in a display like this we need some client-side code. The gem includes client-side modules to: - Manage &lt;b&gt;time and display geometries&lt;/b&gt; with "infinite" scroll along the time axis. - &lt;b&gt;Format display cells&lt;/b&gt; in ways specific to the resource models. - &lt;b&gt;Update text justification&lt;/b&gt; as the display is scrolled horizontally. ## Configuration A **scheduled resource** is something that can be used for one thing at a time. So if "Rocky &amp; Bullwinkle" is on channel 3 from 10am to 11am on Saturday, then 'channel 3' is the &lt;u&gt;resource&lt;/u&gt; and that showing of the episode is a &lt;u&gt;resource-use&lt;/u&gt; block. Resources and use-blocks are typically Rails models. Each resource and its use-blocks get one row in the display. That row has a label to the left with some timespan visible on the rest of the row. Something else you would expect see in a schedule would be headers and labels -- perhaps one row with the date and another row with the hour. Headers and labels also fit the model of resources and use-blocks. Basic timezone-aware classes (ZTime*) for those are included in this gem. ### Config File The schedule configuration comes from &lt;tt&gt;config/resource_schedule.yml&lt;/tt&gt; which has three top-level sections: - ResourceKinds: A hash where the key is a Resource and the value is a UseBlock. (Both are class names), - Resources: A list where each item is a Resource Class followed by one or more resource ids, and - visibleTime: The visible timespan of the schedule in seconds. The example file &lt;tt&gt;config/resource_schedule.yml&lt;/tt&gt; (installed when you run &lt;tt&gt;schedulize&lt;/tt&gt;) should be enough to display a two-row schedule with just the date above and the hour below. Of course you can monkey-patch or subclass these classes for your own needs. ### The schedule API The 'schedule' endpoint uses parameters &lt;tt&gt;t1&lt;/tt&gt; and &lt;tt&gt;t2&lt;/tt&gt; to specify a time interval for the request. A third parameter &lt;tt&gt;inc&lt;/tt&gt; allows an initial time window to be expanded without repeating blocks that span those boundaries. The time parameters _plus the configured resources_ define the data to be returned. ### More About Configuration Management The &lt;b&gt;ScheduledResource&lt;/b&gt; class manages resource and use-block class names, id's and labels for a schedule according to the configuration file. A ScheduledResource instance ties together: 1. A resource class (eg TvStation), 2. An id (a channel number in this example), and 3. Strings and other assets that will go into the DOM. The id is used to - select a resource _instance_ and - select instances of the _resource use block_ class (eg Program instances). The id _could_ be a database id but more often is something a little more suited to human use in the configuration. In any case it is used by model class method &lt;tt&gt;(resource_use_block_class).get_all_blocks()&lt;/tt&gt; to select the right use-blocks for the resource. A resource class name and id are are joined with a '_' to form a tag that also serves as an id for the DOM. Once the configuration yaml is loaded that data is maintained in the session structure. Of course having a single configuration file limits the application's usefulness. A more general approach would be to have a user model with login and configuration would be associated with the user. ## Installation Add this line to your application's Gemfile: ```ruby gem 'scheduled_resource' ``` And then execute: $ bundle Or install it yourself as: $ gem install scheduled_resource Then from your application's root execute: $ schedulize . This will install a few image placeholders, client-side modules and a stylesheet under &lt;tt&gt;vendor/assets&lt;/tt&gt;, an example configuration in &lt;tt&gt;config/resource_schedule.yml&lt;/tt&gt; and an example controller in &lt;tt&gt;app/controllers/schedule_controller.rb&lt;/tt&gt;. Also, if you use $ bundle show scheduled_resource to locate the installed source you can browse example classes &lt;tt&gt;lib/z_time_*.rb&lt;/tt&gt; and the controller helper methods in &lt;tt&gt;lib/scheduled_resource/helper.rb&lt;/tt&gt; ## Testing This gem also provides for a basic test application using angularjs to display a minimal but functional schedule showing just the day and hour headers in two different timezones (US Pacific and Eastern). Proceed as follows, starting with a fresh Rails app: $ rails new test_sr As above, add the gem to the Gemfile, then $ cd test_sr $ bundle $ schedulize . Add lines such as these to &lt;tt&gt;config/routes.rb&lt;/tt&gt; get "/schedule/index" =&gt; "schedule#index" get "/schedule" =&gt; "schedule#schedule" Copy / merge these files from the gem source into the test app: $SR_SRC/app/views/layouts/application.html.erb $SR_SRC/app/views/schedule/index.html.erb $SR_SRC/app/assets/javascripts/{angular.js,script.js,controllers.js} and add &lt;tt&gt;//= require angular&lt;/tt&gt; to application.js just below the entries for &lt;tt&gt;jquery&lt;/tt&gt;. After you run the server and browse to http://0.0.0.0:3000/schedule/index you should see the four time-header rows specified by the sample config file. ## More Examples A better place to see the use of this gem is at [tv4](https://github.com/emeyekayee/tv4). Specifically, models &lt;tt&gt;app/models/event.rb&lt;/tt&gt; and &lt;tt&gt;app/models/station.rb&lt;/tt&gt; give better examples of implementing the ScheduledResource protocol and adapting to a db schema organized along somewhat different lines. ## Contributing 1. Fork it ( https://github.com/emeyekayee/scheduled_resource/fork ) 2. Create your feature branch (`git checkout -b my-new-feature`) 3. Commit your changes (`git commit -am 'Add some feature'`) 4. Push to the branch (`git push origin my-new-feature`) 5. Create a new Pull Request

No description provided.

No description provided.

No description provided.

No description provided.