I am a beginner in OpenWrt router development, I am try to create a hot-spot management system and with social website (such as Facebook, Twitter and LinkedIn) with WifiDog.
I already install wifidog using opkg install using putty, but it's not showing any splash page when I try to connect to the internet (like nodogsplash).
Please see my .conf file below
# $Id$
# WiFiDog Configuration file
# Parameter: GatewayID
# Default: default
# Optional
#
# Set this to the node ID on the auth server
# This is used to give a customized login page to the clients and for
# monitoring/statistics purpose. If you run multiple gateways on the same
# machine each gateway needs to have a different gateway id.
# If none is supplied, the mac address of the GatewayInterface interface will be used,
# without the : separators
# GatewayID default
# Parameter: ExternalInterface
# Default: NONE
# Optional
#
# Set this to the external interface (the one going out to the Inernet or your larger LAN).
# Typically vlan1 for OpenWrt, and eth0 or ppp0 otherwise,
# Normally autodetected
# ExternalInterface eth0
# Parameter: GatewayInterface
# Default: NONE
# Mandatory
#
# Set this to the internal interface (typically your wifi interface).
# Typically br-lan for Openwrt (by default the wifi interface is bridged with wired lan in openwrt)
# and eth1, wlan0, ath0, etc. otherwise
# You can get this interface with the ifconfig command and finding your wifi interface
GatewayInterface br-lan
# Parameter: GatewayAddress
# Default: Find it from GatewayInterface
# Optional
#
# Set this to the internal IP address of the gateway. Not normally required.
# GatewayAddress 192.168.1.1
# Parameter: HtmlMessageFile
# Default: wifidog-msg.html
# Optional
#
# This allows you to specify a custome HTML file which will be used for
# system errors by the gateway. Any $title, $message and $node variables
# used inside the file will be replaced.
#
HtmlMessageFile /etc/wifidog-msg.html
# Parameter: AuthServer
# Default: NONE
# Mandatory, repeatable
#
# This allows you to configure your auth server(s). Each one will be tried in order, untill one responds.
# Set this to the hostname or IP of your auth server(s), the path where
# WiFiDog-auth resides in and the port it listens on.
#AuthServer {
# Hostname (Mandatory; Default: NONE)
# SSLAvailable (Optional; Default: no; Possible values: yes, no)
# SSLPort (Optional; Default: 443)
# HTTPPort (Optional; Default: 80)
# Path (Optional; Default: /wifidog/ Note: The path must be both prefixed and suffixed by /. Use a single / for server root.)
# LoginScriptPathFragment (Optional; Default: login/? Note: This is the script the user will be sent to for login.)
# PortalScriptPathFragment (Optional; Default: portal/? Note: This is the script the user will be sent to after a successfull login.)
# MsgScriptPathFragment (Optional; Default: gw_message.php? Note: This is the script the user will be sent to upon error to read a readable message.)
# PingScriptPathFragment (Optional; Default: ping/? Note: This is the script the user will be sent to upon error to read a readable message.)
# AuthScriptPathFragment (Optional; Default: auth/? Note: This is the script the user will be sent to upon error to read a readable message.)
#}
#AuthServer {
# Hostname auth.ilesansfil.org
# SSLAvailable yes
# Path /
#}
AuthServer {
Hostname mytestserver.com
SSLAvailable no
Path /
}
# Parameter: Daemon
# Default: 1
# Optional
#
# Set this to true if you want to run as a daemon
# Daemon 1
# Parameter: GatewayPort
# Default: 2060
# Optional
#
# Listen on this port
# GatewayPort 2060
# Parameter: ProxyPort
# Default: 0 (disable)
# Optional
#
# Redirect http traffic of knowns & probations users
# to a local transparent proxy listening on ProxyPort port
# ProxyPort 0
# Parameter: HTTPDName
# Default: WiFiDog
# Optional
#
# Define what name the HTTPD server will respond
# HTTPDName WiFiDog
# Parameter: HTTPDMaxConn
# Default: 10
# Optional
#
# How many sockets to listen to
# HTTPDMaxConn 10
# Parameter: HTTPDRealm
# Default: WiFiDog
# Optional
#
# The name of the HTTP authentication realm. This only used when a user
# tries to access a protected WiFiDog internal page. See HTTPUserName.
# HTTPDRealm WiFiDog
# Parameter: HTTPDUserName / HTTPDPassword
# Default: unset
# Optional
#
# The gateway exposes some information such as the status page through its web
# interface. This information can be protected with a username and password,
# which can be set through the HTTPDUserName and HTTPDPassword parameters.
# HTTPDUserName admin
# HTTPDPassword secret
# Parameter: CheckInterval
# Default: 60
# Optional
#
# How many seconds should we wait between timeout checks. This is also
# how often the gateway will ping the auth server and how often it will
# update the traffic counters on the auth server. Setting this too low
# wastes bandwidth, setting this too high will cause the gateway to take
# a long time to switch to it's backup auth server(s).
# CheckInterval 60
# Parameter: ClientTimeout
# Default: 5
# Optional
#
# Set this to the desired of number of CheckInterval of inactivity before a client is logged out
# The timeout will be INTERVAL * TIMEOUT
ClientTimeout 5
# Parameter: TrustedMACList
# Default: none
# Optional
#
# Comma separated list of MAC addresses who are allowed to pass
# through without authentication
#TrustedMACList 00:00:DE:AD:BE:AF,00:00:C0:1D:F0:0D
# Parameter: FirewallRuleSet
# Default: none
# Mandatory
#
# Groups a number of FirewallRule statements together.
# Parameter: FirewallRule
# Default: none
#
# Define one firewall rule in a rule set.
# Rule Set: global
#
# Used for rules to be applied to all other rulesets except locked.
FirewallRuleSet global {
# FirewallRule syntax:
# FirewallRule (block|drop|allow|log|ulog) [(tcp|udp|icmp) [port X]] [to IP/CIDR]
## To block SMTP out, as it's a tech support nightmare, and a legal liability
#FirewallRule block tcp port 25
## Use the following if you don't want clients to be able to access machines on
## the private LAN that gives internet access to wifidog. Note that this is not
## client isolation; The laptops will still be able to talk to one another, as
## well as to any machine bridged to the wifi of the router.
# FirewallRule block to 192.168.0.0/16
# FirewallRule block to 172.16.0.0/12
# FirewallRule block to 10.0.0.0/8
## This is an example ruleset for the Teliphone service.
#FirewallRule allow udp to 69.90.89.192/27
#FirewallRule allow udp to 69.90.85.0/27
#FirewallRule allow tcp port 80 to 69.90.89.205
## Use the following to log or ulog the traffic you want to allow or block.
# For OPENWRT: use of these feature requires modules ipt_LOG or ipt_ULOG present in dependencies
# iptables-mod-extra and iptables-mod-ulog (to adapt it to the linux distribution).
# Note: the log or ulog rule must be passed before, the rule you want to match.
# for openwrt: use of these feature requires modules ipt_LOG or ipt_ULOG present in dependencies
# iptables-mod-extra and iptables-mod-ulog
# For example, you want to log (ulog works the same way) the traffic allowed on port 80 to the ip 69.90.89.205:
#FirewallRule log tcp port 80 to 69.90.89.205
#FirewallRule allow tcp port 80 to 69.90.89.205
# And you want to know, who matche your block rule:
#FirewallRule log to 0.0.0.0/0
#FirewallRule block to 0.0.0.0/0
FirewallRule allow mytestserver.com
}
# Rule Set: validating-users
#
# Used for new users validating their account
FirewallRuleSet validating-users {
FirewallRule allow to 0.0.0.0/0
}
# Rule Set: known-users
#
# Used for normal validated users.
FirewallRuleSet known-users {
FirewallRule allow to 0.0.0.0/0
}
# Rule Set: unknown-users
#
# Used for unvalidated users, this is the ruleset that gets redirected.
#
# XXX The redirect code adds the Default DROP clause.
FirewallRuleSet unknown-users {
FirewallRule allow udp port 53
FirewallRule allow tcp port 53
FirewallRule allow udp port 67
FirewallRule allow tcp port 67
FirewallRule allow to 0.0.0.0/0
}
# Rule Set: locked-users
#
# Not currently used
FirewallRuleSet locked-users {
FirewallRule block to 0.0.0.0/0
}
I think u can try our apfree wifidog project
https://github.com/liudf0716/apfree_wifidog
we have integrated our project with openwrt closely, u don't need to write your own wifidog conf, just using our openwrt style config file, our wifidog.init can parse your parameters auto, for example, the following openwrt style wifidog config file :
config wifidog
option gateway_interface 'br-lan'
option auth_server_hostname 'entrance.kunteng.org'
option auth_server_port 80
option auth_server_path '/wifidog/'
option check_interval 60
option client_timeout 72000
option httpd_max_conn 200
option pool_mode 1
option thread_number 5
option queue_size 20
option wired_passed 1
u just change your own auth_server_hostname, auth_server_port and auth_server_path
You also need to set GatewayID the same as configuration in AuthServer. and set GatewayPort 2060.
if your AuthServer is authpuppy, the AuthServer path may be changed to /authpuppy/web/.
try this wifidog configuration and update wifidog
Go to System > Software - Click -> Update List after that
Type "Wifidog" filter package box to search.
From list install wifidog.
#Gateway ID is use from Hotspot ID
GatewayID XXXXXX
ExternalInterface eth0
#GatewayInterface br-lan
AuthServer {
Hostname wan.cloudwifizone.com
HTTPPort 80
Path /
}
HTTPDMaxConn 253
ClientTimeout 10
PopularServers kernel.org,ieee.org,cloudwifizone.com,ask.com
FirewallRuleSet global {
FirewallRule allow to 8.8.8.8
}
FirewallRuleSet validating-users {
FirewallRule allow to 0.0.0.0/0
}
FirewallRuleSet known-users {
FirewallRule allow to 0.0.0.0/0
}
FirewallRuleSet unknown-users {
FirewallRule allow udp port 53
FirewallRule allow tcp port 53
FirewallRule allow udp port 67
FirewallRule allow tcp port 67
FirewallRule block udp port 8000
}
FirewallRuleSet locked-users {
FirewallRule block to 0.0.0.0/0
}
#TrustedMACList 00:00:DE:AD:BE:AF,00:00:C0:1D:F0:0D
source cloudwifizone.com
Related
Context
I'm trying to learn how to use secure cookies using a very simple nodejs server that returns basic html over localhost:3000. I was told I would need to set up a reverse proxy in order to get SSL working so you can best have your development environment mimic that of what production would be like. I realize that I can learn how secure cookies work over localhost without a reverse proxy, but I wanted the challenge and to learn how to get SSL set up in a development environment.
Setup
I personally prefer to develop in WSL (WSL 2, Ubuntu-20.04) so naturally I set up the node server in WSL along with Caddy Server with the following configuration provided by the levelup tutorials course I'm using to teach me about web authentication. I ran Caddy Server by running caddy run in the directory I had the following file.
{
local_certs
}
nodeauth.dev {
reverse_proxy 127.0.0.1:3000
}
The following were the startup logs for the Caddy Server
2021/07/01 00:53:18.253 INFO using adjacent Caddyfile
2021/07/01 00:53:18.256 WARN input is not formatted with 'caddy fmt' {"adapter": "caddyfile", "file": "Caddyfile", "line": 2}
2021/07/01 00:53:18.258 INFO admin admin endpoint started {"address": "tcp/localhost:2019", "enforce_origin": false, "origins": ["localhost:2019", "[::1]:2019", "127.0.0.1:2019"]}
2021/07/01 00:53:18.262 INFO tls.cache.maintenance started background certificate maintenance {"cache": "0xc0003c5260"}
2021/07/01 00:53:18.281 INFO http server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS {"server_name": "srv0", "https_port": 443}
2021/07/01 00:53:18.281 INFO http enabling automatic HTTP->HTTPS redirects {"server_name": "srv0"}
2021/07/01 00:53:18.450 INFO pki.ca.local root certificate is already trusted by system {"path": "storage:pki/authorities/local/root.crt"}
2021/07/01 00:53:18.451 INFO http enabling automatic TLS certificate management {"domains": ["nodeauth.dev"]}
2021/07/01 00:53:18.452 INFO tls cleaning storage unit {"description": "FileStorage:/home/rtclements/.local/share/caddy"}
2021/07/01 00:53:18.454 INFO tls finished cleaning storage units
2021/07/01 00:53:18.454 WARN tls stapling OCSP {"error": "no OCSP stapling for [nodeauth.dev]: no OCSP server specified in certificate"}
2021/07/01 00:53:18.456 INFO autosaved config (load with --resume flag) {"file": "/home/rtclements/.config/caddy/autosave.json"}
2021/07/01 00:53:18.456 INFO serving initial configuration
I also added 127.0.0.1 nodeauth.dev to the hosts file in WSL at /etc/hosts. Below is the resulting file.
# This file was automatically generated by WSL. To stop automatic generation of this file, add the following entry to /etc/wsl.conf:
# [network]
# generateHosts = false
127.0.0.1 localhost
127.0.1.1 MSI.localdomain MSI
192.168.99.100 docker
127.0.0.1 nodeauth.dev
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
Problem
Interestingly enough, I was able to hit the node server via my browser by navigating to localhost:3000 (as expected), and was able to hit the Caddy Server by navigating to localhost:2019. The following was the log outputted by Caddy Server when I hit it.
2021/07/01 00:53:32.224 INFO admin.api received request {"method": "GET", "host": "localhost:2019", "uri": "/", "remote_addr": "127.0.0.1:34390", "headers": {"Accept":["*/*"],"User-Agent":["curl/7.68.0"]}}
I am not, however, able to see the html from my node server in my browser by navigating to nodeauth.dev. Neither am I seeing any output from running curl nodeauth.dev in my console in WSL, whereas I get the expected output when I run curl localhost:3000 also in WSL. Why is this?
I figured it had to do something with the hosts file on Windows not including this configuration. So I tried modifying that file to look like this, but I still couldn't get it to work.
# Copyright (c) 1993-2009 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
# 102.54.94.97 rhino.acme.com # source server
# 38.25.63.10 x.acme.com # x client host
# localhost name resolution is handled within DNS itself.
# 127.0.0.1 localhost
# ::1 localhost
192.168.99.100 docker
127.0.0.1 nodeauth.dev
I tried running a powershell script that I barely understand that I found from here, but that didn't work either, and I was no longer able to access localhost:3000. I'm guessing it does some form of port forwarding. Code below.
If (-NOT ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator"))
{
$arguments = "& '" + $myinvocation.mycommand.definition + "'"
Start-Process powershell -Verb runAs -ArgumentList $arguments
Break
}
# create the firewall rule to let in 443/80
if( -not ( get-netfirewallrule -displayname web -ea 0 )) {
new-netfirewallrule -name web -displayname web -enabled true -profile any -action allow -localport 80,443 -protocol tcp
}
$remoteport = bash.exe -c "ifconfig eth0 | grep 'inet '"
$found = $remoteport -match '\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}';
if( $found ){
$remoteport = $matches[0];
} else{
echo "The Script Exited, the ip address of WSL 2 cannot be found";
exit;
}
$ports=#(80,443);
iex "netsh interface portproxy reset";
for( $i = 0; $i -lt $ports.length; $i++ ){
$port = $ports[$i];
iex "netsh interface portproxy add v4tov4 listenport=$port connectport=$port connectaddress=$remoteport";
}
iex "netsh interface portproxy show v4tov4";
The only thing that worked was when I ran Caddy Server on Windows with the same configuration and changes to the hosts files as shown before. I'm not terribly sure what's going on here, but would any of y'all happen to know?
I want to disable rsh and rlogin. I have disable 513 and 154 port in iptables,but I still can login with rsh on another host.I'm working on Debian7.8 32bit
my /etc/inetd.conf is here
# /etc/inetd.conf: see inetd(8) for further informations.
#
# Internet superserver configuration database
#
#
# Lines starting with "#:LABEL:" or "#<off>#" should not
# be changed unless you know what you are doing!
#
# If you want to disable an entry so it isn't touched during
# package updates just comment it out with a single '#' character.
#
# Packages should modify this file by using update-inetd(8)
#
# <service_name> <sock_type> <proto> <flags> <user> <server_path> <args>
#
#:INTERNAL: Internal services
#discard stream tcp nowait root internal
#discard dgram udp wait root internal
#daytime stream tcp nowait root internal
#time stream tcp nowait root internal
#:STANDARD: These are standard services.
#:BSD: Shell, login, exec and talk are BSD protocols.
#:MAIL: Mail, news and uucp services.
#:INFO: Info services
#:BOOT: TFTP service is provided primarily for booting. Most sites
# run this only on machines acting as "boot servers."
#:RPC: RPC based services
#:HAM-RADIO: amateur-radio services
#:OTHER: Other services
#<off># netbios-ssn stream tcp nowait root /usr/sbin/tcpd /usr/sbin/smbd
swat stream tcp nowait.400 root /usr/sbin/tcpd /usr/sbin/swat
#<off># sane-port stream tcp nowait saned:saned /usr/sbin/saned saned
Modify the disable field in the configuration file /etc/xinetd.d/rlogin and /etc/xinetd.d/rsh
Then use the command service xinetd restart to restart the xinetd service
I am trying to develop a proxy server which will help clients to auto logged into my application without password by setting cookies on that session in proxy.
It means if user is using proxy to access that site then he will auto logged into that site using cookie set on that traffic.
I already installed & configured SQUID on centos 6.8 x64.
After setting everything & using
request_header_add Cookie name=value
in /etc/squid/squid.conf.
The cookie is set to all HTTP traffic but my application uses HTTPS.
So, i tried to setup OpenSSl, ssl-bump, and all the setup regarding SSL including ip tables
This is how my squid.conf looks like:
acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow all
http_port 3130
http_port 3128 intercept
https_port 3129 intercept ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=8MB cert=/etc/squid/ssl_cert/myca.pem key=/etc/squid/ssl_cert/myca.pem
request_header_add Cookie name=value all
#always_direct allow all
ssl_bump server-first all
#sslproxy_cert_error deny all
#sslproxy_flags DONT_VERIFY_PEER
sslcrtd_program /usr/lib64/squid/ssl_crtd -s /var/lib/ssl_db -M 8MB
sslcrtd_children 8 startup=1 idle=1
After researching more i also activate ip tables to forward packets to proxy for intercept.
iptables -t nat -A PREROUTING -p tcp -s 0.0.0.0/0 -j DNAT --to-destination 192.2xx.xx4.xx4:3128 --dport 80
iptables -t nat -A PREROUTING -p tcp -s 0.0.0.0/0 -j DNAT --to-destination 192.2xx.xx4.xx4:3129 --dport 443
Above configuration is working fine without any issue on HTTP traffic
But still the Cookie header is not added to "HTTPS" traffic.
My main motive is to logged into the application if anyone use this proxy without entering login details using cookie set into HTTPS header.
Can anyone help me to tell that this task can be done to setup cookie (Change header) on HTTPS traffic using SQUID or not.
If possible please help me to find out the error or what else i have to do.
Thanks in advance !
I am running a spring boot service using spring data redis and here is the following configuration.
The service seems to work but I am seeing a stream of Lost Sentinel messages in the logs. The sentinel nodes are reachable form the VM where I am running the service. I was able to telnet to them directly from that VM. Any idea why this is happening?
spring:
profiles:
active: core-perf,swagger
default: core-perf,swagger
redis:
Pool: #Pool properties
# Max number of "idle" connections in the pool. Use a negative value to indicate
# an unlimited number of idle connections.
maxIdle: 8
# Target for the minimum number of idle connections to maintain in the pool.
# This setting only has an effect if it is positive.
minIdle: 0
# Max number of connections that can be allocated by the pool at a given time. Use a negative value for no limit.
maxActive: 8
# Maximum amount of time (in milliseconds) a connection allocation should block
# before throwing an exception when the pool is exhausted. Use a negative value
# to block indefinitely.
maxWait: -1
sentinel: #Redis sentinel properties.
master: mymaster
nodes: 10.202.56.209:26379, 10.202.56.213:26379, 10.202.58.80:26379
2015-06-15 17:30:54.896 ERROR 6677 --- [Thread-9] redis.clients.jedis.JedisSentinelPool : Lost connection to Sentinel at 10.202.58.80:26379. Sleeping 5000ms and retrying.
2015-06-15 17:30:59.894 ERROR 6677 --- [Thread-8] redis.clients.jedis.JedisSentinelPool : Lost connection to Sentinel at 10.202.56.213:26379. Sleeping 5000ms and retrying.
2015-06-15 17:30:59.897 ERROR 6677 --- [Thread-9] redis.clients.jedis.JedisSentinelPool : Lost connection to Sentinel at 10.202.58.80:26379. Sleeping 5000ms and retrying.
2015-06-15 17:31:04.975 ERROR 6677 --- [Thread-9] redis.clients.jedis.JedisSentinelPool : Lost connection to Sentinel at 10.202.58.80:26379. Sleeping 5000ms and retrying.
2015-06-15 17:31:04.976 ERROR 6677 --- [Thread-8] redis.clients.jedis.JedisSentinelPool : Lost connection to Sentinel at 10.202.56.213:26379. Sleeping 5000ms and retrying.
2015-06-15 17:31:09.976 ERROR 6677 --- [Thread-9] redis.clients.jedis.JedisSentinelPool : Lost connection to Sentinel at 10.202.58.80:26379. Sleeping 5000ms and retrying.
2015-06-15 17:31:09.976 ERROR 6677 --- [Thread-8] redis.clients.jedis.JedisSentinelPool : Lost connection to Sentinel at 10.202.56.213:26379. Sleeping 5000ms and retrying.
2015-06-15 17:31:15.054 ERROR 6677 --- [Thread-8] redis.clients.jedis.JedisSentinelPool : Lost connection to Sentinel at 10.202.56.213:26379. Sleeping 5000ms and retrying.
2015-06-15 17:31:15.055 ERROR 6677 --- [Thread-9] redis.clients.jedis.JedisSentinelPool : Lost connection to Sentinel at 10.202.58.80:26379. Sleeping 5000ms and retrying.
2015-06-15 17:31:20.055 ERROR 6677 --- [Thread-8] redis.clients.jedis.JedisSentinelPool : Lost connection to Sentinel at 10.202.56.213:26379. Sleeping 5000ms and retrying.
We discovered the issue. There was a blank between the node pairs in the application.yml and once we removed this " " the Lost Sentinel log message disappeared.
so from
nodes: 10.202.56.209:26379, 10.202.56.213:26379, 10.202.58.80:26379
to
nodes: 10.202.56.209:26379,10.202.56.213:26379,10.202.58.80:26379
It would probably be a good thing if the committers looked at this as it would seem to be somewhat mysterious for users.
I lost my head over this issue for 2 days until I decided to reinstall it again and then configure it via my old config files and then after replacing sentinel.conf file with the below text.
It finally worked.
# *** IMPORTANT ***
#
# By default Sentinel will not be reachable from interfaces different than
# localhost, either use the 'bind' directive to bind to a list of network
# interfaces, or disable protected mode with "protected-mode no" by
# adding it to this configuration file.
#
# Before doing that MAKE SURE the instance is protected from the outside
# world via firewalling or other means.
#
# For example you may use one of the following:
#
# bind 127.0.0.1 192.168.1.1
#
# protected-mode no
# port <sentinel-port>
# The port that this sentinel instance will run on
port 26379
# By default Redis Sentinel does not run as a daemon. Use 'yes' if you need it.
# Note that Redis will write a pid file in /var/run/redis-sentinel.pid when
# daemonized.
daemonize no
# When running daemonized, Redis Sentinel writes a pid file in
# /var/run/redis-sentinel.pid by default. You can specify a custom pid file
# location here.
pidfile /var/run/redis-sentinel.pid
# Specify the log file name. Also the empty string can be used to force
# Sentinel to log on the standard output. Note that if you use standard
# output for logging but daemonize, logs will be sent to /dev/null
logfile ""
# sentinel announce-ip <ip>
# sentinel announce-port <port>
#
# The above two configuration directives are useful in environments where,
# because of NAT, Sentinel is reachable from outside via a non-local address.
#
# When announce-ip is provided, the Sentinel will claim the specified IP address
# in HELLO messages used to gossip its presence, instead of auto-detecting the
# local address as it usually does.
#
# Similarly when announce-port is provided and is valid and non-zero, Sentinel
# will announce the specified TCP port.
#
# The two options don't need to be used together, if only announce-ip is
# provided, the Sentinel will announce the specified IP and the server port
# as specified by the "port" option. If only announce-port is provided, the
# Sentinel will announce the auto-detected local IP and the specified port.
#
# Example:
#
# sentinel announce-ip 1.2.3.4
# dir <working-directory>
# Every long running process should have a well-defined working directory.
# For Redis Sentinel to chdir to /tmp at startup is the simplest thing
# for the process to don't interfere with administrative tasks such as
# unmounting filesystems.
dir /tmp
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
#
# Tells Sentinel to monitor this master, and to consider it in O_DOWN
# (Objectively Down) state only if at least <quorum> sentinels agree.
#
# Note that whatever is the ODOWN quorum, a Sentinel will require to
# be elected by the majority of the known Sentinels in order to
# start a failover, so no failover can be performed in minority.
#
# Replicas are auto-discovered, so you don't need to specify replicas in
# any way. Sentinel itself will rewrite this configuration file adding
# the replicas using additional configuration options.
# Also note that the configuration file is rewritten when a
# replica is promoted to master.
#
# Note: master name should not include special characters or spaces.
# The valid charset is A-z 0-9 and the three characters ".-_".
sentinel monitor mymaster 127.0.0.1 6379 2
# sentinel auth-pass <master-name> <password>
#
# Set the password to use to authenticate with the master and replicas.
# Useful if there is a password set in the Redis instances to monitor.
#
# Note that the master password is also used for replicas, so it is not
# possible to set a different password in masters and replicas instances
# if you want to be able to monitor these instances with Sentinel.
#
# However you can have Redis instances without the authentication enabled
# mixed with Redis instances requiring the authentication (as long as the
# password set is the same for all the instances requiring the password) as
# the AUTH command will have no effect in Redis instances with authentication
# switched off.
#
# Example:
#
# sentinel auth-pass mymaster MySUPER--secret-0123passw0rd
# sentinel auth-user <master-name> <username>
#
# This is useful in order to authenticate to instances having ACL capabilities,
# that is, running Redis 6.0 or greater. When just auth-pass is provided the
# Sentinel instance will authenticate to Redis using the old "AUTH <pass>"
# method. When also an username is provided, it will use "AUTH <user> <pass>".
# In the Redis servers side, the ACL to provide just minimal access to
# Sentinel instances, should be configured along the following lines:
#
# user sentinel-user >somepassword +client +subscribe +publish \
# +ping +info +multi +slaveof +config +client +exec on
# sentinel down-after-milliseconds <master-name> <milliseconds>
#
# Number of milliseconds the master (or any attached replica or sentinel) should
# be unreachable (as in, not acceptable reply to PING, continuously, for the
# specified period) in order to consider it in S_DOWN state (Subjectively
# Down).
#
# Default is 30 seconds.
sentinel down-after-milliseconds mymaster 30000
# IMPORTANT NOTE: starting with Redis 6.2 ACL capability is supported for
# Sentinel mode, please refer to the Redis website https://redis.io/topics/acl
# for more details.
# Sentinel's ACL users are defined in the following format:
#
# user <username> ... acl rules ...
#
# For example:
#
# user worker +#admin +#connection ~* on >ffa9203c493aa99
#
# For more information about ACL configuration please refer to the Redis
# website at https://redis.io/topics/acl and redis server configuration
# template redis.conf.
# ACL LOG
#
# The ACL Log tracks failed commands and authentication events associated
# with ACLs. The ACL Log is useful to troubleshoot failed commands blocked
# by ACLs. The ACL Log is stored in memory. You can reclaim memory with
# ACL LOG RESET. Define the maximum entry length of the ACL Log below.
acllog-max-len 128
# Using an external ACL file
#
# Instead of configuring users here in this file, it is possible to use
# a stand-alone file just listing users. The two methods cannot be mixed:
# if you configure users here and at the same time you activate the external
# ACL file, the server will refuse to start.
#
# The format of the external ACL user file is exactly the same as the
# format that is used inside redis.conf to describe users.
#
# aclfile /etc/redis/sentinel-users.acl
# requirepass <password>
#
# You can configure Sentinel itself to require a password, however when doing
# so Sentinel will try to authenticate with the same password to all the
# other Sentinels. So you need to configure all your Sentinels in a given
# group with the same "requirepass" password. Check the following documentation
# for more info: https://redis.io/topics/sentinel
#
# IMPORTANT NOTE: starting with Redis 6.2 "requirepass" is a compatibility
# layer on top of the ACL system. The option effect will be just setting
# the password for the default user. Clients will still authenticate using
# AUTH <password> as usually, or more explicitly with AUTH default <password>
# if they follow the new protocol: both will work.
#
# New config files are advised to use separate authentication control for
# incoming connections (via ACL), and for outgoing connections (via
# sentinel-user and sentinel-pass)
#
# The requirepass is not compatable with aclfile option and the ACL LOAD
# command, these will cause requirepass to be ignored.
# sentinel sentinel-user <username>
#
# You can configure Sentinel to authenticate with other Sentinels with specific
# user name.
# sentinel sentinel-pass <password>
#
# The password for Sentinel to authenticate with other Sentinels. If sentinel-user
# is not configured, Sentinel will use 'default' user with sentinel-pass to authenticate.
# sentinel parallel-syncs <master-name> <numreplicas>
#
# How many replicas we can reconfigure to point to the new replica simultaneously
# during the failover. Use a low number if you use the replicas to serve query
# to avoid that all the replicas will be unreachable at about the same
# time while performing the synchronization with the master.
sentinel parallel-syncs mymaster 1
# sentinel failover-timeout <master-name> <milliseconds>
#
# Specifies the failover timeout in milliseconds. It is used in many ways:
#
# - The time needed to re-start a failover after a previous failover was
# already tried against the same master by a given Sentinel, is two
# times the failover timeout.
#
# - The time needed for a replica replicating to a wrong master according
# to a Sentinel current configuration, to be forced to replicate
# with the right master, is exactly the failover timeout (counting since
# the moment a Sentinel detected the misconfiguration).
#
# - The time needed to cancel a failover that is already in progress but
# did not produced any configuration change (SLAVEOF NO ONE yet not
# acknowledged by the promoted replica).
#
# - The maximum time a failover in progress waits for all the replicas to be
# reconfigured as replicas of the new master. However even after this time
# the replicas will be reconfigured by the Sentinels anyway, but not with
# the exact parallel-syncs progression as specified.
#
# Default is 3 minutes.
sentinel failover-timeout mymaster 180000
# SCRIPTS EXECUTION
#
# sentinel notification-script and sentinel reconfig-script are used in order
# to configure scripts that are called to notify the system administrator
# or to reconfigure clients after a failover. The scripts are executed
# with the following rules for error handling:
#
# If script exits with "1" the execution is retried later (up to a maximum
# number of times currently set to 10).
#
# If script exits with "2" (or an higher value) the script execution is
# not retried.
#
# If script terminates because it receives a signal the behavior is the same
# as exit code 1.
#
# A script has a maximum running time of 60 seconds. After this limit is
# reached the script is terminated with a SIGKILL and the execution retried.
# NOTIFICATION SCRIPT
#
# sentinel notification-script <master-name> <script-path>
#
# Call the specified notification script for any sentinel event that is
# generated in the WARNING level (for instance -sdown, -odown, and so forth).
# This script should notify the system administrator via email, SMS, or any
# other messaging system, that there is something wrong with the monitored
# Redis systems.
#
# The script is called with just two arguments: the first is the event type
# and the second the event description.
#
# The script must exist and be executable in order for sentinel to start if
# this option is provided.
#
# Example:
#
# sentinel notification-script mymaster /var/redis/notify.sh
# CLIENTS RECONFIGURATION SCRIPT
#
# sentinel client-reconfig-script <master-name> <script-path>
#
# When the master changed because of a failover a script can be called in
# order to perform application-specific tasks to notify the clients that the
# configuration has changed and the master is at a different address.
#
# The following arguments are passed to the script:
#
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
#
# <state> is currently always "failover"
# <role> is either "leader" or "observer"
#
# The arguments from-ip, from-port, to-ip, to-port are used to communicate
# the old address of the master and the new address of the elected replica
# (now a master).
#
# This script should be resistant to multiple invocations.
#
# Example:
#
# sentinel client-reconfig-script mymaster /var/redis/reconfig.sh
# SECURITY
#
# By default SENTINEL SET will not be able to change the notification-script
# and client-reconfig-script at runtime. This avoids a trivial security issue
# where clients can set the script to anything and trigger a failover in order
# to get the program executed.
sentinel deny-scripts-reconfig yes
# REDIS COMMANDS RENAMING
#
# Sometimes the Redis server has certain commands, that are needed for Sentinel
# to work correctly, renamed to unguessable strings. This is often the case
# of CONFIG and SLAVEOF in the context of providers that provide Redis as
# a service, and don't want the customers to reconfigure the instances outside
# of the administration console.
#
# In such case it is possible to tell Sentinel to use different command names
# instead of the normal ones. For example if the master "mymaster", and the
# associated replicas, have "CONFIG" all renamed to "GUESSME", I could use:
#
# SENTINEL rename-command mymaster CONFIG GUESSME
#
# After such configuration is set, every time Sentinel would use CONFIG it will
# use GUESSME instead. Note that there is no actual need to respect the command
# case, so writing "config guessme" is the same in the example above.
#
# SENTINEL SET can also be used in order to perform this configuration at runtime.
#
# In order to set a command back to its original name (undo the renaming), it
# is possible to just rename a command to itself:
#
# SENTINEL rename-command mymaster CONFIG CONFIG
# HOSTNAMES SUPPORT
#
# Normally Sentinel uses only IP addresses and requires SENTINEL MONITOR
# to specify an IP address. Also, it requires the Redis replica-announce-ip
# keyword to specify only IP addresses.
#
# You may enable hostnames support by enabling resolve-hostnames. Note
# that you must make sure your DNS is configured properly and that DNS
# resolution does not introduce very long delays.
#
SENTINEL resolve-hostnames no
# When resolve-hostnames is enabled, Sentinel still uses IP addresses
# when exposing instances to users, configuration files, etc. If you want
# to retain the hostnames when announced, enable announce-hostnames below.
#
SENTINEL announce-hostnames no
ERROR:
c:\Users\dhawal.vora>vagrant ssh
`ssh` executable not found in any directories in the %PATH% variable. Is an
SSH client installed? Try installing Cygwin, MinGW or Git, all of which
contain an SSH client. Or use your favorite SSH client with the following
authentication information shown below:
Host: 127.0.0.1
Port: 2222
Username: vagrant
Private key: c:/Users/dhawal.vora/.vagrant/machines/default/virtualbox/private_key
Kindly help????
Vagrant file is below-
# -*- mode: ruby -*-
# vi: set ft=ruby :
# All Vagrant configuration is done below. The "2" in Vagrant.configure
# configures the configuration version (we support older styles for
# backwards compatibility). Please don't change it unless you know what
# you're doing.
Vagrant.configure(2) do |config|
# The most common configuration options are documented and commented below.
# For a complete reference, please see the online documentation at
# https://docs.vagrantup.com.
# Every Vagrant development environment requires a box. You can search for
# boxes at https://atlas.hashicorp.com/search.
config.vm.box = "precise32"
# Disable automatic box update checking. If you disable this, then
# boxes will only be checked for updates when the user runs
# `vagrant box outdated`. This is not recommended.
config.vm.box_check_update = false
# Create a forwarded port mapping which allows access to a specific port
# within the machine from a port on the host machine. In the example below,
# accessing "localhost:8080" will access port 80 on the guest machine.
# config.vm.network "forwarded_port", guest: 80, host: 8080
# Create a private network, which allows host-only access to the machine
# using a specific IP.
# config.vm.network "private_network", ip: "192.168.33.10"
# Create a public network, which generally matched to bridged network.
# Bridged networks make the machine appear as another physical device on
# your network.
config.vm.network "public_network"
# Share an additional folder to the guest VM. The first argument is
# the path on the host to the actual folder. The second argument is
# the path on the guest to mount the folder. And the optional third
# argument is a set of non-required options.
config.vm.synced_folder "../data", "/vagrant_data"
# Provider-specific configuration so you can fine-tune various
# backing providers for Vagrant. These expose provider-specific options.
# Example for VirtualBox:
#
# config.vm.provider "virtualbox" do |vb|
# # Display the VirtualBox GUI when booting the machine
# vb.gui = true
#
# # Customize the amount of memory on the VM:
# vb.memory = "1024"
# end
#
# View the documentation for the provider you are using for more
# information on available options.
# Define a Vagrant Push strategy for pushing to Atlas. Other push strategies
# such as FTP and Heroku are also available. See the documentation at
# https://docs.vagrantup.com/v2/push/atlas.html for more information.
# config.push.define "atlas" do |push|
# push.app = "YOUR_ATLAS_USERNAME/YOUR_APPLICATION_NAME"
# end
# Enable provisioning with a shell script. Additional provisioners such as
# Puppet, Chef, Ansible, Salt, and Docker are also available. Please see the
# documentation for more information about their specific syntax and use.
# config.vm.provision "shell", inline <<-SHELL
sudo apt-get install apache2
# SHELL
end
Adding C:\Program Files\Git\usr\bin to the PATH environment variable.
Add it manually or I believe you could run this in cmd:
set PATH=%PATH%;C:\Program Files\Git\usr\bin
updated from #Ygor Thomaz's comments
or (64 bits)
set PATH=%PATH%;C:\Program Files\Git\usr\bin
If this doesn't fix your problem, go through :
Get SSH working on Vagrant/Windows/Git
You can alternatively install openssh from here and then you can add the ssh.exe to your PATH by:
set PATH=%PATH%;C:\Program Files (x86)\OpenSSH\bin
or
set PATH=%PATH%;C:\Program Files\OpenSSH\bin
With Windows 10 I also couldn't get the 'set PATH' option to work. But when I amended the PATH variable through System Settings and started a new command prompt it worked fine.
Also, putty worked perfectly after I read the screen which told me to use a username of 'core'.
'core' was a requirement of my configuration which was trying to launch CoreOS.
Adding C:\Program Files\Git\usr\bin to the PATH environment variable didn't work for me.
So I configured PUTTY for ssh connection.
This well-written illustrative tutorial gives a great overview on ways to setup Vagrant SSH. The first way is via Git and the second way describes how to use Putty. It is very easy to follow.
Running Vagrant SSH on Windows
In my case even adding ssh to the PATH didn't solve the problem. What I had to do is connect to vagrant with ssh manually. After executing vagrant up, instead of executing vagrant ssh, I do this:
ssh vagrant#127.0.0.1 -p 2222
And the password is "vagrant"
For getting all the information about the ip, port and user you can use
vagrant ssh-config
Ope this helps somebody...