search for: hostaliases

...webmail. However, I'd say that your roundcubemail.conf is much overworked. We use something like that on openssl.org, but it generally looks like this: <VirtualHost *:80> ServerAdmin webmaster at localhost ServerName ${HOSTNAME} ServerAlias ${HOSTALIASES} Redirect permanent /https://${HOSTNAME}/ </VirtualHost> Since you already know that the host is correct and that's the port 80 virtualhost, there's no point testing that with those RewriteCond you have. Also, Redirect is faster and preferable to RewriteRule...

...f so, you may need to stop them or flush their cache. What do you get if you "dig @localhost localhost +short".? If that doesn't return a "localhost" address, then the name server that you're running has a broken configuration. Do you get any output from "echo $HOSTALIASES"?

...much >> overworked. We use something like that on openssl.org, but it >> generally looks like this: >> >> <VirtualHost *:80> >> ServerAdmin webmaster at localhost >> ServerName ${HOSTNAME} >> ServerAlias ${HOSTALIASES} >> >> Redirect permanent /https://${HOSTNAME}/ >> </VirtualHost> >> >> Since you already know that the host is correct and that's the port 80 >> virtualhost, there's no point testing that with those RewriteCond you >>...

...that your roundcubemail.conf is much > overworked. We use something like that on openssl.org, but it > generally looks like this: > > <VirtualHost *:80> > ServerAdmin webmaster at localhost > ServerName ${HOSTNAME} > ServerAlias ${HOSTALIASES} > > Redirect permanent /https://${HOSTNAME}/ > </VirtualHost> > > Since you already know that the host is correct and that's the port 80 > virtualhost, there's no point testing that with those RewriteCond you > have. Also, Redirect is faste...

...that you're > running has a broken configuration. ; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> @localhost localhost +short ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached > > Do you get any output from "echo $HOSTALIASES"? No output from the above > Thanks!!

...way to do this might be to add command line options to the ControlPath variable, so different (at least explicit) options will create a new Master connection, but there?s nothing like that in the TOKENS at the moment. Could something like that be added or is there a nice workaround? (Not including hostaliases just for this). I can?t be the only one who hit this. I would propose something like: %O Base64 encoded command line options given to ssh(1) (While it might be nice to normalize -A and -o ForwardAgent=yes to the same ?hash?, I don?t think it?s worth it and this would suffice) Thanks Jan

On 08/24/2018 05:40 PM, TE Dukes wrote: > >> ??? getent hosts localhost > ::1 localhost Can't say that's what I expected.? What about "getent hosts 127.0.0.1"? Also, uncomment the ::1 line in /etc/hosts. >> Can you reach localhost by "normal" means? >> ??? telnet localhost 25 > I cannot. Can you share the specific

...d. We use something like that on openssl.org, but it >>> generally looks like this: >>> >>> <VirtualHost *:80> >>> ServerAdmin webmaster at localhost >>> ServerName ${HOSTNAME} >>> ServerAlias ${HOSTALIASES} >>> >>> Redirect permanent /https://${HOSTNAME}/ >>> </VirtualHost> >>> >>> Since you already know that the host is correct and that's the port 80 >>> virtualhost, there's no point testing that with those R...

Hello... Is this a bug or by design? I''m using exported resources to generate /etc/ssh/ssh_known_hosts. I changed the example from the docs to this: @@sshkey { "$fqdn,$hostname,$ipaddress": type => rsa, key => $sshrsakey, } so that I would get one line per host in the ssh_know_hosts file. What happened was that on each run several (all?)