| package main | |
| import ( | |
| "context" | |
| "fmt" | |
| "io/ioutil" | |
| "net" | |
| "net/http" | |
| "os" | |
| "time" |
| // This code is in Public domain. | |
| MF_SCHEME_NAME = 3; | |
| MF_NAV = 4; | |
| MF_DATE = 5; | |
| CACHE_NAME = '_mfcache'; | |
| function initNAV() { | |
| var response = UrlFetchApp.fetch("http://portal.amfiindia.com/spages/NAVAll.txt"); | |
| var txt = response.getContentText(); |
| name: Release | |
| on: | |
| release: | |
| types: | |
| - published | |
| jobs: | |
| release: | |
| name: Release | |
| runs-on: ubuntu-latest |
Note: This script has been tested on linux and macos
This document shows how to deploy an OpenShift instance on a server using CodeReady Containers (crc) that can be accessed remotely from one or more client machines (sometimes called a "headless" instance). This provides a low-cost test and development platform that can be shared by developers. Deploying this way also allows a user to create an instance that uses more cpu and memory resources than may be available on his or her laptop.
While there are benefits to this type of deployment, please note that the primary use case for crc is to deploy a local OpenShift instance on a workstation or laptop and access it directly from the same machine. The headless setup is configured completely outside of crc itself, and supporting a headless setup is beyond the mission of the crc development team. Please do not ask for changes to crc to support this type of deployment, it will only cost the team time as they politely decline :)
The instructions here were tested with F
Following steps work for F29 for F31 look here
cat /etc/redhat-release
Fedora release 29 (Twenty Nine)
| title | published | description | tags |
|---|---|---|---|
Running CoreDNS as a DNS Server in a Container |
true |
How to manually configure CoreDNS to serve your own DNS zones and |
dns, coredns, container, docker |
This article is published at:
If you've ever needed to or wanted to set up your own DNS server, then this is for you. I recently found myself in possession of a Raspberry Pi, and instead of relying on my home router for DHCP and DNS, I decided to serve both from containers on the Pi, so I could resolve all of my hosts with their respective names when I VPN back to my network. I intended to have all other requests forwarded to another server that weren't in my local network, but still service local systems with my customized hostnames.
| # These have to be extracted from the qcow2 image | |
| # TODO: Provide these via docker image? | |
| KERNEL="vmlinuz-3.10.0-862.14.4.el7.x86_64" | |
| INITRD="initramfs-3.10.0-862.14.4.el7.x86_64.img" | |
| # This is where the magic happens | |
| # | |
| # To change the ignition (node type), you can use 'bootstrap', 'master' or 'worker' | |
| # coreos.config.url=http://192.168.0.168:8080/bootstrap.ign | |
| # |
