Re: chromium http://localhost:80

[gene heskett]

On 1/22/24 10:23, Max Nikulin wrote:

On 22/01/2024 02:50, gene heskett wrote:

browser: chromium


It was also true here using the file:// prefix, trying look at the 
html versions of the man pages in /usr/share/local/docs.


/usr/share may be unavailable inside snap or flatpack sandboxes, so it 
is expected. Even /etc/hosts, /etc/resolv.conf, /etc/nsswitch.conf may 
differ in the mount namespace created for chromium. It might be 
necessary to use a tool like nsenter to inspect runtime environment of 
the process.


nsenter? Never heard of it before, but I have the man page so I'll 
certainly study it, thank you Max for making me aware of it.

.


Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

chromium http://localhost:80

[Max Nikulin]

On 22/01/2024 02:50, gene heskett wrote:

browser: chromium


It was also true here using the file:// prefix, trying look at the html 
versions of the man pages in /usr/share/local/docs.


/usr/share may be unavailable inside snap or flatpack sandboxes, so it 
is expected. Even /etc/hosts, /etc/resolv.conf, /etc/nsswitch.conf may 
differ in the mount namespace created for chromium. It might be 
necessary to use a tool like nsenter to inspect runtime environment of 
the process.

Re: systemctl status mariadb - Access denied for user root at localhost using password NO

[Andy Smith]

Hello,

On Mon, Oct 02, 2023 at 04:45:25PM +0300, Petros Pap wrote:
> root@server:~# mysql -u root
> ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using
> password: NO)

I believe that the Debian packaging of MariaDB is by default set up
to allow socket authentication for root@localhost so that any root
process can connect to root@localhost through the socket without
supplying a password. I also believe that this is required for
correct functioning of the packaging.

If that no longer works for you, then you or something you ran must
have changed it.

> Can you please advise me what to do?

You should re-enable socket authentication for root@localhost.

If you also need to have things connect to root@localhost by
password then I believe you can allow socket OR password auth. A
simple search will tell you how to do this in MariaDB.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

systemctl status mariadb - Access denied for user root at localhost using password NO

[Petros Pap]

-- System Information:
Debian GNU/Linux 12 (bookworm)
Linux server 6.1.0-12-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.52-1
(2023-09-07) x86_64 GNU/Linux
Version: systemd 252 (252.12-1~deb12u1) +PAM +AUDIT +SELINUX +APPARMOR +IMA
+SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2
+IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT
+QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP
+SYSVINIT default-hierarchy=unified


-- Issue
I have installed Webmin, mariadb, and phpmyadmin

All the above is working
I can create databases from Webmin and create databases from phpmyadmin
and i can login to mysql

root@server:~# mysql -u root
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using
password: NO)
root@server:~# mysql -u root -p
Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 5958
Server version: 10.11.3-MariaDB-1 Debian 12

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input
statement.

MariaDB [(none)]>


But when i try


root@server:~# systemctl stop mariadb.service
root@server:~# systemctl restart mariadb.service
root@server:~# systemctl status mariadb.service
● mariadb.service - MariaDB 10.11.3 database server
 Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; preset:
enabled)
 Active: active (running) since Mon 2023-10-02 16:04:54 EEST; 17s ago
   Docs: man:mariadbd(8)
 https://mariadb.com/kb/en/library/systemd/
Process: 153057 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root
-d /var/run/mysqld (code=exited, status=0/SUCCESS)
Process: 153058 ExecStartPre=/bin/sh -c systemctl unset-environment
_WSREP_START_POSITION (code=exited, status=0/SUCCESS)
Process: 153060 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery
] && VAR= ||   VAR=`cd /usr/bin/..; /usr/bin/galera_recovery`; [ $? -eq 0 ]
  && s>
Process: 153144 ExecStartPost=/bin/sh -c systemctl unset-environment
_WSREP_START_POSITION (code=exited, status=0/SUCCESS)
Process: 153146 ExecStartPost=/etc/mysql/debian-start (code=exited,
status=0/SUCCESS)
   Main PID: 153131 (mariadbd)
 Status: "Taking your SQL requests now..."
  Tasks: 14 (limit: 14299)
 Memory: 172.9M
CPU: 744ms
 CGroup: /system.slice/mariadb.service
 └─153131 /usr/sbin/mariadbd

Oct 02 16:04:53 server systemd[1]: Starting mariadb.service - MariaDB
10.11.3 database server...
Oct 02 16:04:54 server systemd[1]: Started mariadb.service - MariaDB
10.11.3 database server.
Oct 02 16:04:54 server /etc/mysql/debian-start[153151]: Reading datadir
from the MariaDB server failed. Got the following error when executing th>
Oct 02 16:04:54 server /etc/mysql/debian-start[153151]: ERROR 1045 (28000):
Access denied for user 'root'@'localhost' (using password: NO)
Oct 02 16:04:54 server /etc/mysql/debian-start[153151]: FATAL ERROR:
Upgrade failed
Oct 02 16:04:54 server debian-start[153160]: ERROR 1045 (28000): Access
denied for user 'root'@'localhost' (using password: NO)


I don't know if the problem is from systemctl or from mariadb or from
phpmyadmin,
I believe is systemctl because everything else seems is working

Can you please advise me what to do?

-- 
ppetros

Re: [Solved] Re: localhost web apps and cookie blocking

[Celejar]

On Fri, 16 Apr 2021 12:42:14 -0400
Dan Ritter  wrote:

> Celejar wrote: 
> > Interesting. I thought my usecase was a pretty straightforward one - I
> > have various typical home user services that I have no intention of
> > making available on the public internet, so I don't bother with SSL,
> > but I do want to access them relatively securely across my local
> > network. port forwarding via ssh seemed like an easy and solid
> > solution, but perhaps it's not commonly done.
> 
> Fairly common. You can add stanzas like this:
> 
> (nginx):
> 
> location /someserver/ {
> proxy_pass http://127.0.0.1:/;
> proxy_set_header Host $host;
> proxy_set_header X-Real-IP $remote_addr;
> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
> proxy_set_header X-Forwarded-Proto $scheme;
> proxy_set_header Connection "";
> allow 192.168.0.0/24;
> allow 127.0.0.1;
> deny all;
> }
> 
> This changes it from a port number to a URL path, allows your
> local network and localhost to access it, and denies it to
> others, should they come across the path.
> 
> Apache and other webservers can do similar things.

Thanks. I've considered setting up a reverse proxy (either nginx, or
Caddy / Traefik / something else), but I haven't bothered yet. The web
apps I use have their own, self-contained servers.

Celejar

Re: [Solved] Re: localhost web apps and cookie blocking

[Dan Ritter]

Celejar wrote: 
> Interesting. I thought my usecase was a pretty straightforward one - I
> have various typical home user services that I have no intention of
> making available on the public internet, so I don't bother with SSL,
> but I do want to access them relatively securely across my local
> network. port forwarding via ssh seemed like an easy and solid
> solution, but perhaps it's not commonly done.

Fairly common. You can add stanzas like this:

(nginx):

location /someserver/ {
proxy_pass http://127.0.0.1:/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Connection "";
allow 192.168.0.0/24;
allow 127.0.0.1;
deny all;
}

This changes it from a port number to a URL path, allows your
local network and localhost to access it, and denies it to
others, should they come across the path.

Apache and other webservers can do similar things.

-dsr-

[Solved] Re: localhost web apps and cookie blocking

[Celejar]

On Fri, 16 Apr 2021 17:26:36 +0300
Reco  wrote:

>   Hi.
> 
> On Fri, Apr 16, 2021 at 09:45:13AM -0400, Celejar wrote:
> > I have various web (HTTP, not HTTPS) apps (e.g., pi-hole, Home
> > Assistant) running on localhost (either actually on localhost, or on
> > another host but accessed via 'localhost' via ssh port forwarding
> > (LocalForward) that require cookies to function (even before logging
> > in). When Firefox is set to block all cookies, these don't work - even
> > though I have an exception set to allow cookies from localhost.
> 
> Because firefox cookie exceptions actually apply to schema-hostname-port
> triplet, but not to the hostname itself.
> I.e. if you allowed Firefox to store cookies from http://localhost:80
> (what you've called "localhost"), but trying to use
> http://localhost:8080 to access some HTTP service - cookies from
> http://localhost:8080 won't be allowed.

Awesome, thanks so much! I think I once came up with that idea myself,
but discarded it since "Manage Cookies and Site Data" doesn't show port
numbers, only hostnames. But adding 'http:/localhost:' does indeed
work (and it shows up as schema-hostname-port in "Exceptions - Cookie
and Site Data").

> > (Examining the cookie store ("Manage Cookies and Site Data")
> > doesn't show any cookies stored from any site other than localhost.)
> 
> "Manage Cookies and Site Data" was likely written on the assumption that
> a single hostname provides a single site, at most serving both HTTP and
> HTTPS versions of the same content. I suspect that your usecase differs
> from these assumptions somewhat.

Interesting. I thought my usecase was a pretty straightforward one - I
have various typical home user services that I have no intention of
making available on the public internet, so I don't bother with SSL,
but I do want to access them relatively securely across my local
network. port forwarding via ssh seemed like an easy and solid
solution, but perhaps it's not commonly done.

Thanks again,

Celejar

Re: localhost web apps and cookie blocking

[Reco]

Hi.

On Fri, Apr 16, 2021 at 09:45:13AM -0400, Celejar wrote:
> I have various web (HTTP, not HTTPS) apps (e.g., pi-hole, Home
> Assistant) running on localhost (either actually on localhost, or on
> another host but accessed via 'localhost' via ssh port forwarding
> (LocalForward) that require cookies to function (even before logging
> in). When Firefox is set to block all cookies, these don't work - even
> though I have an exception set to allow cookies from localhost.

Because firefox cookie exceptions actually apply to schema-hostname-port
triplet, but not to the hostname itself.
I.e. if you allowed Firefox to store cookies from http://localhost:80
(what you've called "localhost"), but trying to use
http://localhost:8080 to access some HTTP service - cookies from
http://localhost:8080 won't be allowed.

> (Examining the cookie store ("Manage Cookies and Site Data")
> doesn't show any cookies stored from any site other than localhost.)

"Manage Cookies and Site Data" was likely written on the assumption that
a single hostname provides a single site, at most serving both HTTP and
HTTPS versions of the same content. I suspect that your usecase differs
from these assumptions somewhat.

Reco

localhost web apps and cookie blocking

[Celejar]

Hi,

I have various web (HTTP, not HTTPS) apps (e.g., pi-hole, Home
Assistant) running on localhost (either actually on localhost, or on
another host but accessed via 'localhost' via ssh port forwarding
(LocalForward) that require cookies to function (even before logging
in). When Firefox is set to block all cookies, these don't work - even
though I have an exception set to allow cookies from localhost. The
only way I can access these apps is via relaxing Firefox's Enhanced
Tracking Protection to allow (at least) first party cookies in general.
Why? (Examining the cookie store ("Manage Cookies and Site Data")
doesn't show any cookies stored from any site other than localhost.)

This doesn't seem to be an issue for normal web sites, where
whitelisting the website is (generally?) sufficient to get the sites to
work. What am I missing?

Celejar

Re: localhost

[Daryl]

On Sun, 2 Feb 2020 19:40:24 +
"Russell L. Harris"  wrote:

> I am attempting to configure Apache2 (in Debian 10) as a local server
> for web site development.
> 
> I see on the "Apache2 Debian Default Page" the Debian logo; the
> browser reports the image location as:
> 
> http://localhost/icons/openlogo-75.png
> 
> But when I use midnight commander to snoop around \var and other
> directories, I find no directory named "localhost".
> 
> The immediate goal of my investigation is to discover the location
> (with respect to "var/www" or "public_html") to which essential images
> such as web site logos and navigation button icons should be uploaded.
> 
> This investigation is part of my exploration of the "Perl Template
> Toolkit".  I am proceeding step-by-step through the tutorial presented
> in chapter 11 of the O'Reilly "Badger Book", but I do yet understand
> why images are not being displayed.
> 
> 

Localhost isn't a directory. It is the hostname from /etc/hosts. The
directory comes from what is configured
in /etc/apache2/sites-available/000-default.conf

Default is /var/www/html

So if you do:

printf "Found my localhost root directory\n" >> /var/www/html/test.txt

You can then navigate to http://localhost/test.txt and you'll see your
new message in your browser.

Re: localhost

[Marco Shaw]

Apache is a whole different beast with things like its own directory aliases. 

This may help:
https://httpd.apache.org/docs/2.4/getting-started.html

Marco

> On Feb 2, 2020, at 3:40 PM, Russell L. Harris  wrote:
> 
> I am attempting to configure Apache2 (in Debian 10) as a local server
> for web site development.
> 
> I see on the "Apache2 Debian Default Page" the Debian logo; the
> browser reports the image location as:
> 
>   http://localhost/icons/openlogo-75.png
> 
> But when I use midnight commander to snoop around \var and other
> directories, I find no directory named "localhost".
> 
> The immediate goal of my investigation is to discover the location
> (with respect to "var/www" or "public_html") to which essential images
> such as web site logos and navigation button icons should be uploaded.
> 
> This investigation is part of my exploration of the "Perl Template
> Toolkit".  I am proceeding step-by-step through the tutorial presented
> in chapter 11 of the O'Reilly "Badger Book", but I do yet understand
> why images are not being displayed.
> 
> 

localhost

[Russell L. Harris]

I am attempting to configure Apache2 (in Debian 10) as a local server
for web site development.

I see on the "Apache2 Debian Default Page" the Debian logo; the
browser reports the image location as:

   http://localhost/icons/openlogo-75.png

But when I use midnight commander to snoop around \var and other
directories, I find no directory named "localhost".

The immediate goal of my investigation is to discover the location
(with respect to "var/www" or "public_html") to which essential images
such as web site logos and navigation button icons should be uploaded.

This investigation is part of my exploration of the "Perl Template
Toolkit".  I am proceeding step-by-step through the tutorial presented
in chapter 11 of the O'Reilly "Badger Book", but I do yet understand
why images are not being displayed.

Re: password refused by cups on localhost:631 (fwd)

[Brian]

On Tue 03 Dec 2019 at 16:13:19 -0500, Gene Heskett wrote:

> On Tuesday 03 December 2019 14:23:34 Brian wrote:
> 
> > On Tue 03 Dec 2019 at 13:17:21 -0500, Gene Heskett wrote:
> > > On Tuesday 03 December 2019 11:37:59 Pierre Frenkiel wrote:
> > > > On Sat, 30 Nov 2019, Roberto C. Sanchez wrote:
> > > > It has a been a while, but my recollection is that you add a
> > > > normal user to the lpadmin group.  Then by authenticating as that
> > > > user you can administer through the web interface.
> > > >
> > > > hi Roberto,
> > > > alas, I already did that, without success.
> > >
> > > When it pops up the requester, did you change it from the default
> > > root to your name you've added to lpadmin and your passwd?  That
> > > works here.
> >
> > I wish I could have confidence in your interpretation of what you see.
> > The pop-up has two blank fields. Why you maintain the default user is
> > "root" and it needs to be changed is beyond me.
> 
> Well, since about 6.04 of the ubuntu thread, its always popped up with 
> the root line filled with "root", and about 15 dots that represents the 
> missing root pw. I just change them both to me & my pw and it sorta 
> works.

Ubuntu? You might have noticed we are talking about behaviour on Debian.
You'll have checked, of course. Well, perhaps not. It's easier to hark
back to some dim menory of a long forgotten distribution.

-- 
Brian.

solved - Re: password refused by cups on localhost:631

[Pierre Frenkiel]

On Tue, 3 Dec 2019, Brian wrote:


I wish I could have confidence in your interpretation of what you see.
The pop-up has two blank fields. Why you maintain the default user is
"root" and it needs to be changed is beyond me.


  Yes, I maintain it...
  I don't have 2 blank fields,
  but 2 fields containing "root" and the registred root password
  Anyway, I found that there were 2 running cupsd.
  After killing one, everything works fine, i.e for either root or me,
  the password is accepted.

  thanks everybody for your advices.

best regards,
--
Pierre Frenkiel

Re: password refused by cups on localhost:631 (fwd)

[Gene Heskett]

On Tuesday 03 December 2019 15:58:45 Pierre Frenkiel wrote:

> On Tue, 3 Dec 2019, Gene Heskett wrote:
> > When it pops up the requester, did you change it from the default
> > root to your name you've added to lpadmin and your passwd?  That
> > works here.
>
>yes, I do that, and my password is refused, as well as the root one
And your /etc/group entry for lpadmin resembles this?:
lpadmin:x:116:gene


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: password refused by cups on localhost:631 (fwd)

[Gene Heskett]

On Tuesday 03 December 2019 14:23:34 Brian wrote:

> On Tue 03 Dec 2019 at 13:17:21 -0500, Gene Heskett wrote:
> > On Tuesday 03 December 2019 11:37:59 Pierre Frenkiel wrote:
> > > On Sat, 30 Nov 2019, Roberto C. Sanchez wrote:
> > > It has a been a while, but my recollection is that you add a
> > > normal user to the lpadmin group.  Then by authenticating as that
> > > user you can administer through the web interface.
> > >
> > > hi Roberto,
> > > alas, I already did that, without success.
> >
> > When it pops up the requester, did you change it from the default
> > root to your name you've added to lpadmin and your passwd?  That
> > works here.
>
> I wish I could have confidence in your interpretation of what you see.
> The pop-up has two blank fields. Why you maintain the default user is
> "root" and it needs to be changed is beyond me.

Well, since about 6.04 of the ubuntu thread, its always popped up with 
the root line filled with "root", and about 15 dots that represents the 
missing root pw. I just change them both to me & my pw and it sorta 
works.

Explaining the "sorta" would be TL;DR and has been posted many times and 
just as many times ignored. Both on this list and the cups list.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: password refused by cups on localhost:631 (fwd)

[Pierre Frenkiel]

On Tue, 3 Dec 2019, Gene Heskett wrote:


When it pops up the requester, did you change it from the default root to
your name you've added to lpadmin and your passwd?  That works here.


  yes, I do that, and my password is refused, as well as the root one

Re: password refused by cups on localhost:631 (fwd)

[Brian]

On Tue 03 Dec 2019 at 13:17:21 -0500, Gene Heskett wrote:

> On Tuesday 03 December 2019 11:37:59 Pierre Frenkiel wrote:
> 
> > On Sat, 30 Nov 2019, Roberto C. Sanchez wrote:
> > It has a been a while, but my recollection is that you add a
> > normal user to the lpadmin group.  Then by authenticating as that user
> > you can administer through the web interface.
> >
> > hi Roberto,
> > alas, I already did that, without success.
> >
> When it pops up the requester, did you change it from the default root to 
> your name you've added to lpadmin and your passwd?  That works here.

I wish I could have confidence in your interpretation of what you see.
The pop-up has two blank fields. Why you maintain the default user is
"root" and it needs to be changed is beyond me.

-- 
Brian.

Re: password refused by cups on localhost:631 (fwd)

[Gene Heskett]

On Tuesday 03 December 2019 11:37:59 Pierre Frenkiel wrote:

> On Sat, 30 Nov 2019, Roberto C. Sanchez wrote:
> It has a been a while, but my recollection is that you add a
> normal user to the lpadmin group.  Then by authenticating as that user
> you can administer through the web interface.
>
> hi Roberto,
> alas, I already did that, without success.
>
When it pops up the requester, did you change it from the default root to 
your name you've added to lpadmin and your passwd?  That works here. 

Cumbersome but works. On a system w/o a root passwd, I use sudo for 
everything, I haven't a clue how cups expects to get a valid passwd for 
root. Boggles the mind, but it insists.  So change it yourself.

> no more answers 
> nobody can give an advice?
>
> best regards,


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: password refused by cups on localhost:631 (fwd)

[Brian]

On Tue 03 Dec 2019 at 17:37:59 +0100, Pierre Frenkiel wrote:

> On Sat, 30 Nov 2019, Roberto C. Sanchez wrote:
>It has a been a while, but my recollection is that you add a normal user
>to the lpadmin group.  Then by authenticating as that user you can
>administer through the web interface.
> 
>hi Roberto,
>alas, I already did that, without success.
> 
> no more answers 
> nobody can give an advice?

After being added to a group a user has to log out and log in again.
Can we assume you have not altered any .conf file in /etc/cups?

-- 
Brian.

Re: password refused by cups on localhost:631 (fwd)

[Pierre Frenkiel]

On Sat, 30 Nov 2019, Roberto C. Sanchez wrote:
   It has a been a while, but my recollection is that you add a normal user
   to the lpadmin group.  Then by authenticating as that user you can
   administer through the web interface.

   hi Roberto,
   alas, I already did that, without success.

no more answers 
nobody can give an advice?

best regards,
--
Pierre Frenkiel

Re: password refused by cups on localhost:631

[Pierre Frenkiel]

On Sat, 30 Nov 2019, Roberto C. Sanchez wrote:
   It has a been a while, but my recollection is that you add a normal user
   to the lpadmin group.  Then by authenticating as that user you can
   administer through the web interface.

   hi Roberto,
   alas, I already did that, without success.

best regards,
--
Pierre Frenkiel

Re: password refused by cups on localhost:631

[Roberto C . Sánchez]

On Sat, Nov 30, 2019 at 06:01:18PM +0100, Pierre Frenkiel wrote:
> hi,
> I tried to add a printer using the localhost:631 cups interface,
> but the root password was refused, as well as mine
> To be sure that the provided password was valid, I reset it with the
> passwd command.
> can anybody explain that?
> 
It has a been a while, but my recollection is that you add a normal user
to the lpadmin group.  Then by authenticating as that user you can
administer through the web interface.

Regards,

-Roberto

-- 
Roberto C. Sánchez

password refused by cups on localhost:631

[Pierre Frenkiel]

hi,
I tried to add a printer using the localhost:631 cups interface,
but the root password was refused, as well as mine
To be sure that the provided password was valid, I reset it with the
passwd command.
can anybody explain that?

best regards,
--
Pierre Frenkiel

smbclient not finding share for localhost

[Frank Miles]

My home linux/Debian/buster machine has suddenly made samba 'shares' 
invisible to my Win7 virtual machine (running under kvm/qemu).

Using smbclient I get two different responses:

  smbclient -L localhost

only gives the error-message response:

  Unable to initialize messaging context
  Connection to localhost failed (Error NT_STATUS_UNSUCCESSFUL)

But if I given the IP address:
   smbclient -L 192.168.1.20
it asks for a password, then tells me about the shares:
  Unable to initialize messaging context
  Enter WORKGROUP\user's password:
   ...shares...
   server info
   workgroup info

If I do the same thing on another computer (running Stretch), I
don't get the messaging-context whining, and after entering my
password get the information whether I've given it 'localhost'
or the IP address as an argument.  Unfortunately the sambas
are a different version, so I don't think I can directly compare
their configuration.  In case you wonder, testparm's [global]
output is:
[global]
bind interfaces only = Yes
deadtime = 1440
dns proxy = No
domain master = Yes
interfaces = br0 eth0 127.0.0.0/8
keepalive = 5
log file = /var/log/samba/log.%m
map to guest = Bad User
max log size = 1000
name resolve order = wins lmhosts bcast
obey pam restrictions = Yes
pam password change = Yes
panic action = /usr/share/samba/panic-action %d
passwd chat = *Enter\snew\s*\spassword:* %n\n 
*Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
passwd program = /usr/bin/passwd %u
server role = standalone server
unix password sync = Yes
username map = /etc/samba/username.map
usershare allow guests = Yes
wins server = 192.168.1.20
idmap config * : backend = tdb
hosts allow = 192.168.0.0/16 127.0.0.1
hosts deny = ALL

Any hints or pointers to the Fine Manual gratefully received!
   -Frank
{AFAICR I hadn't changed smb.conf since when it had been working.
And I've tried this with the firewall completely off}

Re: cannot open display: localhost:0.0

[Greg Wooledge]

On Sun, Sep 23, 2018 at 11:51:29AM -0400, Gene Heskett wrote:
> gene@rock64:~$ sudo netstat -anp|grep 6000
> [sudo] password for gene:
> gene@rock64:~$ sudo netstat -anp|grep 6000
> gene@rock64:~$ 
> 
> Nothing returned, did it twice while logged into the rock64 as 
> UID=1000=gene
> 
> What is this telling me?

That your X server isn't listening to TCP.  Which is normal in this
century.  That's why we have DISPLAY=:0 instead of DISPLAY=localhost:0.

(Or, your X server isn't running at all.  But since you seemed to expect
to see something, I'm guessing that you actually do have X running, so
my first answer is probably what you want.)

Re: cannot open display: localhost:0.0 [solved]

[Rob van der Putten]

Hi there


On 23/09/2018 20:07, Grzesiek Sójka wrote:


On 9/23/18 2:36 PM, Rob van der Putten wrote:


On 23/09/2018 13:48, Grzegorz Sójka wrote:

I need to allow remote applications to connect to xorg. Since I log 
in using lxdm i have tcp_listen=1 in /etc/lxdm/lxdm.conf. Thus Xorg 
is running without -nolisten tcp flag. Unfortunately:


$ xhost +localhost; DISPLAY=localhost:0.0 xterm
localhost being added to access control list
xterm: Xt error: Can't open display: localhost:0.0

Any suggestions??


Did you check port 6000?
root@pc6:~# netstat -anp | grep 6000
tcp   0   0 0.0.0.0:6000   0.0.0.0:*   LISTEN   2684/Xorg
tcp6  0   0 :::6000    :::*    LISTEN   2684/Xorg


Bingo! The command gave me empty output.


Always start low level.

Now -nolisten tcp is the 
default Xorg behaviour. Thus, you need to add -listen tcp flag 
explicitly.


That changed some time ago.


I added:
arg=/usr/bin/X -background vt07 -listen tcp
to /etc/lxdm/lxdm.conf and now it works perfectly.


Sometimes it's in /etc/X11/xdm/Xservers or /etc/X11/xinit/xserverrc
With lightdm it's in /etc/lightdm/lightdm.conf;
xserver-allow-tcp=true


Regards,
Rob

Re: cannot open display: localhost:0.0 [solved]

[Grzesiek Sójka]

On 9/23/18 2:36 PM, Rob van der Putten wrote:

Hi there


On 23/09/2018 13:48, Grzegorz Sójka wrote:

I need to allow remote applications to connect to xorg. Since I log in 
using lxdm i have tcp_listen=1 in /etc/lxdm/lxdm.conf. Thus Xorg is 
running without -nolisten tcp flag. Unfortunately:


$ xhost +localhost; DISPLAY=localhost:0.0 xterm
localhost being added to access control list
xterm: Xt error: Can't open display: localhost:0.0

Any suggestions??


Did you check port 6000?
root@pc6:~# netstat -anp | grep 6000
tcp   0   0 0.0.0.0:6000   0.0.0.0:*   LISTEN   2684/Xorg
tcp6  0   0 :::6000    :::*    LISTEN   2684/Xorg


Bingo! The command gave me empty output. Now -nolisten tcp is the 
default Xorg behaviour. Thus, you need to add -listen tcp flag 
explicitly. I added:

arg=/usr/bin/X -background vt07 -listen tcp
to /etc/lxdm/lxdm.conf and now it works perfectly.

--
Pozdrawiam
Grzesiek

Wysłane z kompa wolnego od wirusów Billa Gatesa.

Re: cannot open display: localhost:0.0

[Étienne Mollier]

On 9/23/18 4:00 PM, Gene Heskett wrote:
> On Sunday 23 September 2018 06:30:01 Étienne Mollier wrote:
> > Maybe try:
> >
> > xhost +LOCAL:
> > DISPLAY=localhost:0.0 xterm
>
> On which machine? The target of the ssh login, or this one
> with the comfy office chair to sit it?

That is not clear out of the context indeed.  In that very
situation, there is no remote host considered yet.  The purpose
was to demonstrate local graphical connection through the TCP
stack, instead of Unix sockets like it is usually done by X
nowadays.  Except it that the graphical server is seemingly
reluctant to work in this configuration.


Let's clarify a bit.  By convention, “local” will be the
terminal on your desk, and “remote”, the target of the SSH
login.  Their use in commands should be replaced by machines' IP
addresses; or name definition in “/etc/hosts” if applicable.

To run remote X application through TCP connections, one had
firstly to ensure the X server was listening to TCP connections;
of course this check was never done, as long as it was a default
behavior.  Debian, and most today's distributions, ship by
default with X servers that don't listen to TCP, so that is not
obvious to establish TCP listening.  It is highly dependent on
the way X is started (through GDM3, KDM, SDDM, LightDM, startx,
or whatever).  For instance, by using startx, I have in my
“/etc/X11/xinit/xserverrc”:

#!/bin/sh
exec /usr/bin/X -nolisten tcp "$@"

As you can see, the option to not listen to TCP connections is
clearly specified.  When I happen to need a listening X server,
I don't tamper with my main display, and use another X server
instead, like “Xephyr”, that I launch on display “:1” for
instance.

Secondly, the current session had to be configured to authorize
X client from “remote” host:

local$ xhost +remote

I believe there are ways to do some basic per-user authorization
as well, this is documented in the manual of xhost(1).  Far too
often, I saw the easy solution consisting in allowing every one
on the network to tamper with one's X server (big transparent
window in foreground to annoy the neighbour, anyone?), but it
sure does the job:

local$ xhost +  # Don't do that!

Last point was to setup properly the environment on the remote
host at the beginning of the session, through the setting of
DISPLAY variable in the environment.  Assuming the X server,
started on the local host, opened its display on :1, the setting
should be:

remote$ DISPLAY=local:1
remote$ export DISPLAY
remote$ xterm

You can check the display on your local machine by doing, on a
newly opened shell window:

local$ echo "$DISPLAY"
:1

/Theoretically/, X programs should start properly, and appear on
the screen of the “local” machine.  Wayland has been mentioned,
so that may not even work well on desktop environment running on
top of Wayland instead of X11.


X11 forwarding functions differently, as instead of using a
dedicated TCP connection to the X server on the local machine,
the X client running on the remote machine babbles through an
SSH connection instead.  That is why it works, even if X doesn't
listen to TCP 6000.


Kind Regards,
-- 
Étienne Mollier 

Re: cannot open display: localhost:0.0

[Gene Heskett]

On Sunday 23 September 2018 10:36:01 Rob van der Putten wrote:

Humm, my puzzle for X11Forwarding has even more pieces.

copy/pasted from the konsole logged into the rock64, running stretch

gene@rock64:~$ sudo netstat -anp|grep 6000
[sudo] password for gene:
gene@rock64:~$ sudo netstat -anp|grep 6000
gene@rock64:~$ 

Nothing returned, did it twice while logged into the rock64 as 
UID=1000=gene

What is this telling me?

Thanks, Rob van der Putten.

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: cannot open display: localhost:0.0

[Gene Heskett]

On Sunday 23 September 2018 09:20:34 Étienne Mollier wrote:

> On 9/23/18 5:06 PM, Grzesiek Sójka wrote:
> > $ xhost +LOCAL: ; DISPLAY=localhost:0.0 xterm
> > non-network local connections being added to access control list
> > xterm: Xt error: Can't open display: localhost:0.0
>
> Whoops, however the DISPLAY=localhost:0.0 was a typo of mine.
> DISPLAY=:0.0 should have been used in that case.  Sorry for the
> typo.
>
> That is not very useful when doing SSH indeed, but for launching
> X applications under another user for instance, when using
> “su -”, it is useful sometimes.
>
> Kind Regards,
I did the xhost +LOCAL:
ok,

but I am still locked out of using synaptic-pkexec as the UID=1000
===paste from local konsole, logged in as gene on rock64
gene@rock64:~$ synaptic-pkexec
 AUTHENTICATING FOR com.ubuntu.pkexec.synaptic ===
Authentication is required to run the Synaptic Package Manager
Authenticating as: Gene Heskett,na,na,unlisted,genuine old fart (gene)
Password:
polkit-agent-helper-1: error response to PolicyKit daemon: 
GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for 
cookie
 AUTHENTICATION FAILED ===
Error executing command as another user: Not authorized
==

Why the heck is it looking for a session cookie? I doubt if its talking 
about the container of chocolate chunk cookies I have at hand here. :)

Thanks for any enlightenment.

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

Re: cannot open display: localhost:0.0

[Rob van der Putten]

Hi there


On 23/09/2018 13:48, Grzegorz Sójka wrote:

I need to allow remote applications to connect to xorg. Since I log in 
using lxdm i have tcp_listen=1 in /etc/lxdm/lxdm.conf. Thus Xorg is 
running without -nolisten tcp flag. Unfortunately:


$ xhost +localhost; DISPLAY=localhost:0.0 xterm
localhost being added to access control list
xterm: Xt error: Can't open display: localhost:0.0

Any suggestions??


Did you check port 6000?
root@pc6:~# netstat -anp | grep 6000
tcp   0   0 0.0.0.0:6000   0.0.0.0:*   LISTEN   2684/Xorg
tcp6  0   0 :::6000:::*LISTEN   2684/Xorg


Regards,
Rob

Re: cannot open display: localhost:0.0

[Gene Heskett]

On Sunday 23 September 2018 06:30:01 Étienne Mollier wrote:

> On 9/23/18 1:48 PM, Grzegorz Sójka wrote:
> > Hi there,
> >
> > I need to allow remote applications to connect to xorg. Since I log
> > in using lxdm i have tcp_listen=1 in /etc/lxdm/lxdm.conf. Thus Xorg
> > is running without -nolisten tcp flag. Unfortunately:
> >
> > $ xhost +localhost; DISPLAY=localhost:0.0 xterm
> > localhost being added to access control list
> > xterm: Xt error: Can't open display: localhost:0.0
> >
> > Any suggestions??
>
> Maybe try:
>
>   xhost +LOCAL:
>   DISPLAY=localhost:0.0 xterm
>
> Kind Regards,

On which machine? The target of the ssh login, or this one with the comfy 
office chair to sit it?

Thanks Étienne Mollier.

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

Re: cannot open display: localhost:0.0

[Étienne Mollier]

On 9/23/18 5:14 PM, Grzesiek Sójka wrote:
> On 9/23/18 1:06 PM, Étienne Mollier wrote:
> > ssh -YC user@remotehost
>
> I do not need encryption since all machines are in the same
> network segment. So I prefer not to use ssh.

In that case, perhaps you should simply test with remote
clients; I don't recall having seen this local connection work
reliably.

Please consider using X forwarding anyway, it induces good
habits when working in less trusted environment.  Furthermore,
I find this way more convenient to set up (I suppose we all have
different tastes, but to me X forwarding  is more seamless than
the whole xhost/Xorg/DISPLAY setting dance.  :-)

If you are concerned about performances, maybe X11 is not the
protocol you are looking for on remote links; especially
regarding today's applications but that is another story.

Kind Regards,
-- 
Étienne Mollier 

Re: cannot open display: localhost:0.0

[Étienne Mollier]

On 9/23/18 5:06 PM, Grzesiek Sójka wrote:
> $ xhost +LOCAL: ; DISPLAY=localhost:0.0 xterm
> non-network local connections being added to access control list
> xterm: Xt error: Can't open display: localhost:0.0

Whoops, however the DISPLAY=localhost:0.0 was a typo of mine.
DISPLAY=:0.0 should have been used in that case.  Sorry for the
typo.

That is not very useful when doing SSH indeed, but for launching
X applications under another user for instance, when using
“su -”, it is useful sometimes.

Kind Regards,
-- 
Étienne Mollier 

Re: cannot open display: localhost:0.0

[Grzesiek Sójka]

On 9/23/18 1:06 PM, Étienne Mollier wrote:

On 9/23/18 2:59 PM, The Wanderer wrote:

On 2018-09-23 at 10:24, Grzesiek Sójka wrote:

On 9/23/18 10:30 AM, Étienne Mollier wrote:

Maybe try:

xhost +LOCAL:
DISPLAY=localhost:0.0 xterm


It does not work:

# xhost +LOCAL; DISPLAY=localhost:0.0 xterm
xhost:  bad hostname "LOCAL"


Did you try with '+LOCAL:' instead of '+LOCAL'?

The colon is important.


Indeed, furthermore if you need to do remote X, using X
forwarding through SSH should be preferred and won't require you
using “xhost” or removing “-nolisten” to Xorg parameters:

ssh -YC user@remotehost


I do not need encryption since all machines are in the same network 
segment. So I prefer not to use ssh.


--
Pozdrawiam
Grzesiek

Wysłane z kompa wolnego od wirusów Billa Gatesa.

Re: cannot open display: localhost:0.0

[Nicolas George]

Étienne Mollier (2018-09-23):
>   or removing “-nolisten” to Xorg parameters:

Finally somebody in this thread who payed attention in the last fifteen
years...

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: cannot open display: localhost:0.0

[Étienne Mollier]

On 9/23/18 2:59 PM, The Wanderer wrote:
> On 2018-09-23 at 10:24, Grzesiek Sójka wrote:
> > On 9/23/18 10:30 AM, Étienne Mollier wrote:
> > > Maybe try:
> > >
> > >   xhost +LOCAL:
> > >   DISPLAY=localhost:0.0 xterm
> >
> > It does not work:
> >
> > # xhost +LOCAL; DISPLAY=localhost:0.0 xterm
> > xhost:  bad hostname "LOCAL"
>
> Did you try with '+LOCAL:' instead of '+LOCAL'?
>
> The colon is important.

Indeed, furthermore if you need to do remote X, using X
forwarding through SSH should be preferred and won't require you
using “xhost” or removing “-nolisten” to Xorg parameters:

ssh -YC user@remotehost

Kind Regards,
-- 
Étienne Mollier 

Re: cannot open display: localhost:0.0

[Grzesiek Sójka]

On 9/23/18 12:59 PM, The Wanderer wrote:

On 2018-09-23 at 10:24, Grzesiek Sójka wrote:


On 9/23/18 10:30 AM, Étienne Mollier wrote:


On 9/23/18 1:48 PM, Grzegorz Sójka wrote:


Hi there,

I need to allow remote applications to connect to xorg. Since I
log in using lxdm i have tcp_listen=1 in /etc/lxdm/lxdm.conf.
Thus Xorg is running without -nolisten tcp flag. Unfortunately:

$ xhost +localhost; DISPLAY=localhost:0.0 xterm
localhost being added to access control list
xterm: Xt error: Can't open display: localhost:0.0

Any suggestions??



Maybe try:

xhost +LOCAL:
DISPLAY=localhost:0.0 xterm


It does not work:

# xhost +LOCAL; DISPLAY=localhost:0.0 xterm
xhost:  bad hostname "LOCAL"


Did you try with '+LOCAL:' instead of '+LOCAL'?

The colon is important.


$ xhost +LOCAL: ; DISPLAY=localhost:0.0 xterm
non-network local connections being added to access control list
xterm: Xt error: Can't open display: localhost:0.0

Please note that I need to enable remote connections. I use localhost 
just for testing.


--
Pozdrawiam
Grzesiek

Wysłane z kompa wolnego od wirusów Billa Gatesa.

Re: cannot open display: localhost:0.0

[The Wanderer]

On 2018-09-23 at 10:24, Grzesiek Sójka wrote:

> On 9/23/18 10:30 AM, Étienne Mollier wrote:
>
>> On 9/23/18 1:48 PM, Grzegorz Sójka wrote:
>>
>>> Hi there,
>>>
>>> I need to allow remote applications to connect to xorg. Since I
>>> log in using lxdm i have tcp_listen=1 in /etc/lxdm/lxdm.conf.
>>> Thus Xorg is running without -nolisten tcp flag. Unfortunately:
>>> 
>>> $ xhost +localhost; DISPLAY=localhost:0.0 xterm
>>> localhost being added to access control list
>>> xterm: Xt error: Can't open display: localhost:0.0
>>>
>>> Any suggestions??
>>>
>> 
>> Maybe try:
>> 
>>  xhost +LOCAL:
>>  DISPLAY=localhost:0.0 xterm
> 
> It does not work:
> 
> # xhost +LOCAL; DISPLAY=localhost:0.0 xterm
> xhost:  bad hostname "LOCAL"

Did you try with '+LOCAL:' instead of '+LOCAL'?

The colon is important.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: cannot open display: localhost:0.0

[Grzesiek Sójka]

On 9/23/18 12:27 PM, Anders Andersson wrote:

On Sun, Sep 23, 2018 at 4:24 PM, Grzesiek Sójka  wrote:

On 9/23/18 10:30 AM, Étienne Mollier wrote:


On 9/23/18 1:48 PM, Grzegorz Sójka wrote:


Hi there,

I need to allow remote applications to connect to xorg. Since I log in
using lxdm i have tcp_listen=1 in /etc/lxdm/lxdm.conf. Thus Xorg is running
without -nolisten tcp flag. Unfortunately:

$ xhost +localhost; DISPLAY=localhost:0.0 xterm
localhost being added to access control list
xterm: Xt error: Can't open display: localhost:0.0

Any suggestions??



Maybe try:

 xhost +LOCAL:
 DISPLAY=localhost:0.0 xterm



It does not work:

# xhost +LOCAL; DISPLAY=localhost:0.0 xterm
xhost:  bad hostname "LOCAL"
xterm: Xt error: Can't open display: localhost:0.0


Are you using Wayland? If you're using debian testing you probably use wayland.


Forgot to mention, I use Sid and xfce4. If i'm not wrong xfce does not 
support Wayland.



--
Pozdrawiam
Grzesiek

Wysłane z kompa wolnego od wirusów Billa Gatesa.

Re: cannot open display: localhost:0.0

[Anders Andersson]

On Sun, Sep 23, 2018 at 4:24 PM, Grzesiek Sójka  wrote:
> On 9/23/18 10:30 AM, Étienne Mollier wrote:
>>
>> On 9/23/18 1:48 PM, Grzegorz Sójka wrote:
>>>
>>> Hi there,
>>>
>>> I need to allow remote applications to connect to xorg. Since I log in
>>> using lxdm i have tcp_listen=1 in /etc/lxdm/lxdm.conf. Thus Xorg is running
>>> without -nolisten tcp flag. Unfortunately:
>>>
>>> $ xhost +localhost; DISPLAY=localhost:0.0 xterm
>>> localhost being added to access control list
>>> xterm: Xt error: Can't open display: localhost:0.0
>>>
>>> Any suggestions??
>>>
>>
>> Maybe try:
>>
>> xhost +LOCAL:
>> DISPLAY=localhost:0.0 xterm
>
>
> It does not work:
>
> # xhost +LOCAL; DISPLAY=localhost:0.0 xterm
> xhost:  bad hostname "LOCAL"
> xterm: Xt error: Can't open display: localhost:0.0

Are you using Wayland? If you're using debian testing you probably use wayland.

Re: cannot open display: localhost:0.0

[Grzesiek Sójka]

On 9/23/18 10:30 AM, Étienne Mollier wrote:

On 9/23/18 1:48 PM, Grzegorz Sójka wrote:

Hi there,

I need to allow remote applications to connect to xorg. Since I log in using 
lxdm i have tcp_listen=1 in /etc/lxdm/lxdm.conf. Thus Xorg is running without 
-nolisten tcp flag. Unfortunately:

$ xhost +localhost; DISPLAY=localhost:0.0 xterm
localhost being added to access control list
xterm: Xt error: Can't open display: localhost:0.0

Any suggestions??



Maybe try:

xhost +LOCAL:
DISPLAY=localhost:0.0 xterm


It does not work:

# xhost +LOCAL; DISPLAY=localhost:0.0 xterm
xhost:  bad hostname "LOCAL"
xterm: Xt error: Can't open display: localhost:0.0

Please note that I need to connect also from remote hosts. I used 
localhost just for testing.


Regards

Re: cannot open display: localhost:0.0

[Étienne Mollier]

On 9/23/18 1:48 PM, Grzegorz Sójka wrote:
> Hi there,
> 
> I need to allow remote applications to connect to xorg. Since I log in using 
> lxdm i have tcp_listen=1 in /etc/lxdm/lxdm.conf. Thus Xorg is running without 
> -nolisten tcp flag. Unfortunately:
> 
> $ xhost +localhost; DISPLAY=localhost:0.0 xterm
> localhost being added to access control list
> xterm: Xt error: Can't open display: localhost:0.0
> 
> Any suggestions??
> 

Maybe try:

    xhost +LOCAL:
DISPLAY=localhost:0.0 xterm

Kind Regards,
-- 
Étienne Mollier 

cannot open display: localhost:0.0

[Grzegorz Sójka]

Hi there,

I need to allow remote applications to connect to xorg. Since I log in 
using lxdm i have tcp_listen=1 in /etc/lxdm/lxdm.conf. Thus Xorg is 
running without -nolisten tcp flag. Unfortunately:


$ xhost +localhost; DISPLAY=localhost:0.0 xterm
localhost being added to access control list
xterm: Xt error: Can't open display: localhost:0.0

Any suggestions??

--
Pozdrawiam
Grzesiek

Wysłane z kompa wolnego od wirusów Billa Gatesa.

Roundcube creates new user with host FQDN instead of localhost

[Tapio Lehtonen]

Debian Stretch, roundcube 1.2.3+dfsg.1-4+deb9u1

Roundcube has created new user_id, with mail_host as FQDN and not 
localhost as previously. last_login with user where mail_host is 
localhost was 21. March, today login is mail_host FQDN.


Can I fix this in the database so address books etc of these two users 
are merged together?


How can I force Roundcube to not do this anymore? I have set
$config['login_lc'] = 2;
to get all lowercase username and domain part, and
$config['default_host'] = 'localhost';
is in both config.inc.php and defaults.inc.php.

--
Tapio Lehtonen
OSK Satatuuli
<>

Re: error: 'Access denied for user 'root'@'localhost' (using password: NO)'

[Joe]

On Sun, 26 Nov 2017 19:11:23 +0100
Ulf Volmer  wrote:

> On 26.11.2017 18:48, Rainer Dorsch wrote:
> 
> > root@scw:/etc/logrotate.d#  cat /etc/mysql/debian.cnf
> > # Automatically generated for Debian scripts. DO NOT TOUCH!
> > [client]
> > host = localhost
> > user = root
> > password = 
> > socket   = /var/run/mysqld/mysqld.sock
> > [mysql_upgrade]
> > host = localhost
> > user = root
> > password = 
> > socket   = /var/run/mysqld/mysqld.sock
> > basedir  = /usr  
> 
> That' not the content i expected. But explains you error message.
> 
> in my system looks like
> 
> # Automatically generated for Debian scripts. DO NOT TOUCH!
> [client]
> host = localhost
> user = debian-sys-maint
> password = long_random_string
> socket   = /var/run/mysqld/mysqld.sock
> [mysql_upgrade]
> host = localhost
> user = debian-sys-maint
> password = long_random_string
> socket   = /var/run/mysqld/mysqld.sock
> basedir  = /usr
> 
> so i think, you should change the user and password in this file. And
> also make sure that the user debian-sys-maint exists in the MySQL
> database and have the configured password.
> 

My guess is that this is a mariadb installation. Is that correct? If
so, check /usr/share/doc/mariadb-server-10.1/README.Debian.gz

"The credentials in /etc/mysql/debian.cnf specify the user which is
used by the init scripts to stop the server and perform logrotation.
This used to be the debian-sys-maint user which is no longer used as
root can run directly.

If you have start/stop problems make sure that
the /etc/mysql/debian.cnf file specifies the root user and no password."

Have you previously changed the password of mysql root?

-- 
Joe

Re: error: 'Access denied for user 'root'@'localhost' (using password: NO)'

[Ulf Volmer]

On 26.11.2017 18:48, Rainer Dorsch wrote:

> root@scw:/etc/logrotate.d#  cat /etc/mysql/debian.cnf
> # Automatically generated for Debian scripts. DO NOT TOUCH!
> [client]
> host = localhost
> user = root
> password = 
> socket   = /var/run/mysqld/mysqld.sock
> [mysql_upgrade]
> host = localhost
> user = root
> password = 
> socket   = /var/run/mysqld/mysqld.sock
> basedir  = /usr

That' not the content i expected. But explains you error message.

in my system looks like

# Automatically generated for Debian scripts. DO NOT TOUCH!
[client]
host = localhost
user = debian-sys-maint
password = long_random_string
socket   = /var/run/mysqld/mysqld.sock
[mysql_upgrade]
host = localhost
user = debian-sys-maint
password = long_random_string
socket   = /var/run/mysqld/mysqld.sock
basedir  = /usr

so i think, you should change the user and password in this file. And
also make sure that the user debian-sys-maint exists in the MySQL
database and have the configured password.

best regards
Ulf

Re: error: 'Access denied for user 'root'@'localhost' (using password: NO)'

[Rainer Dorsch]

On Sonntag, 26. November 2017 17:01:23 CET Joe wrote:
> On Sun, 26 Nov 2017 16:35:24 +0100
> 
> Ulf Volmer  wrote:
> > On 26.11.2017 15:57, Rainer Dorsch wrote:
> > > mysqladmin: connect to server at 'localhost' failed
> > > error: 'Access denied for user 'root'@'localhost' (using password:
> > > NO)' error: error running shared postrotate script for
> > > '/var/log/mysql/mysql.log /
> > > var/log/mysql/mysql-slow.log /var/log/mysql/mariadb-slow.log
> > > /var/log/mysql/ error.log '
> > 
> > did you have manual changes in /etc/logrotate.d/mysql-server or
> > /etc/mysql/debian.cnf? in the last file you will find the credentials
> > for the user debian-sys-maint who is used for maintenance tasks.

I am not aware of any change:

root@scw:/etc/logrotate.d# cat mysql-server 
# - I put everything in one block and added sharedscripts, so that mysql gets
#   flush-logs'd only once.
#   Else the binary logs would automatically increase by n times every day.
# - The error log is obsolete, messages go to syslog now.
/var/log/mysql/mysql.log /var/log/mysql/mysql-slow.log /var/log/mysql/mariadb-
slow.log /var/log/mysql/error.log {
daily
rotate 7
missingok
create 640 mysql adm
compress
sharedscripts
postrotate
  test -x /usr/bin/mysqladmin || exit 0
  if [ -f `my_print_defaults --mysqld | grep -m 1 -oP "pid-file=\K.+$"` 
]; then
# If this fails, check debian.conf!
mysqladmin --defaults-file=/etc/mysql/debian.cnf --local flush-
error-log \
  flush-engine-log flush-general-log flush-slow-log
  fi
    endscript
}
root@scw:/etc/logrotate.d#  cat /etc/mysql/debian.cnf
# Automatically generated for Debian scripts. DO NOT TOUCH!
[client]
host = localhost
user = root
password = 
socket   = /var/run/mysqld/mysqld.sock
[mysql_upgrade]
host = localhost
user = root
password = 
socket   = /var/run/mysqld/mysqld.sock
basedir  = /usr
root@scw:/etc/logrotate.d# 

The only potential candidat I can see is the nextcloud package, which I have 
installed from outside Debian (there is none in Debian), if during the 
installation a change happend I might have missed that.

> > i'm surprised that in the error message above the root user is used.
> 
> That may suggest a mismatch of versions: the logrotate script uses the
> mysqladmin --defaults-file option, which specifies debian-sys-maint in
> the /etc/mysql/debian.cnf file.

I maybe should have mentioned that it is a stretch machine. I just checked for 
packages not in stretch anymore

root@scw:~# apt-show-versions |grep No
gcc-4.8-base:amd64 4.8.4-1 installed: No available version in archive
gcc-4.9-base:amd64 4.9.2-10 installed: No available version in archive
libapt-pkg4.12:amd64 1.0.9.8.3 installed: No available version in archive
libgnutls-deb0-28:amd64 3.3.8-6+deb8u3 installed: No available version in 
archive
libhogweed2:amd64 2.7.1-5+deb8u1 installed: No available version in archive
libicu52:amd64 52.1-8+deb8u4 installed: No available version in archive
libnettle4:amd64 2.7.1-5+deb8u1 installed: No available version in archive
libprocps3:amd64 2:3.3.9-9 installed: No available version in archive
libpsl0:amd64 0.5.1-1 installed: No available version in archive
libreadline6:amd64 6.3-9 installed: No available version in archive
libssl1.0.0:amd64 1.0.1t-1+deb8u5 installed: No available version in archive
linux-image-4.8.0-1-amd64:amd64 4.8.7-1 installed: No available version in 
archive
root@scw:~#

Nothing suspicious for me.

> Old versions of mysqladmin don't have the --defaults-file option
> defined, so may be looking for the root user. A check of man mysqladmin
> on the offending machine should confirm whether the options include
> --defaults-file.

man mysqladmin contains:

   ·   --defaults-file=filename

   Set filename as the file to read default options from, override 
global defaults files. Must be given as first option.

So I should have that...

Thanks
Rainer


-- 
Rainer Dorsch
http://bokomoko.de/

Re: error: 'Access denied for user 'root'@'localhost' (using password: NO)'

[Joe]

On Sun, 26 Nov 2017 16:35:24 +0100
Ulf Volmer  wrote:

> On 26.11.2017 15:57, Rainer Dorsch wrote:
> 
> > mysqladmin: connect to server at 'localhost' failed
> > error: 'Access denied for user 'root'@'localhost' (using password:
> > NO)' error: error running shared postrotate script for
> > '/var/log/mysql/mysql.log /
> > var/log/mysql/mysql-slow.log /var/log/mysql/mariadb-slow.log /var/log/mysql/
> > error.log '  
> 
> did you have manual changes in /etc/logrotate.d/mysql-server or
> /etc/mysql/debian.cnf? in the last file you will find the credentials
> for the user debian-sys-maint who is used for maintenance tasks.
> 
> i'm surprised that in the error message above the root user is used.
> 

That may suggest a mismatch of versions: the logrotate script uses the
mysqladmin --defaults-file option, which specifies debian-sys-maint in
the /etc/mysql/debian.cnf file. 

Old versions of mysqladmin don't have the --defaults-file option
defined, so may be looking for the root user. A check of man mysqladmin
on the offending machine should confirm whether the options include
--defaults-file.

It does on my old mysql-client 5.5.58 installation and my shiny new
mariadb-client 10.0.28 but does not on a mysql 5.5 man page found on
the Net, and may not be in an early mariadb client, I don't know.

-- 
Joe

Re: error: 'Access denied for user 'root'@'localhost' (using password: NO)'

[Ulf Volmer]

On 26.11.2017 15:57, Rainer Dorsch wrote:

> mysqladmin: connect to server at 'localhost' failed
> error: 'Access denied for user 'root'@'localhost' (using password: NO)'
> error: error running shared postrotate script for '/var/log/mysql/mysql.log /
> var/log/mysql/mysql-slow.log /var/log/mysql/mariadb-slow.log /var/log/mysql/
> error.log '

did you have manual changes in /etc/logrotate.d/mysql-server or
/etc/mysql/debian.cnf? in the last file you will find the credentials
for the user debian-sys-maint who is used for maintenance tasks.

i'm surprised that in the error message above the root user is used.

best regards
Ulf

error: 'Access denied for user 'root'@'localhost' (using password: NO)'

[Rainer Dorsch]

Hello,

I get (daily :-) mails from my cron.daily with the content

Cron  test -x /usr/sbin/anacron || ( cd / && run-parts --report /
etc/cron.daily )


/etc/cron.daily/logrotate:
mysqladmin: connect to server at 'localhost' failed
error: 'Access denied for user 'root'@'localhost' (using password: NO)'
error: error running shared postrotate script for '/var/log/mysql/mysql.log /
var/log/mysql/mysql-slow.log /var/log/mysql/mariadb-slow.log /var/log/mysql/
error.log '
run-parts: /etc/cron.daily/logrotate exited with return code 1

When I run it locally

root@scw:~#  test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/
cron.daily )
root@scw:~# 

I do not hit the same issue.

Do I need to specify

   ·   --password[=password], -p[password]

   The password to use when connecting to the server. If you use the 
short option form (-p), you cannot have a space between the option and the 
password. If you omit
   the password value following the --password or -p option on the 
command line, mysqladmin prompts for one.

   Specifying a password on the command line should be considered 
insecure.

to get rid of the issue?

Many thanks
Rainer




-- 
Rainer Dorsch
http://bokomoko.de/

web site problems on localhost

[Gene Heskett]

Greetings;

I found the problem, something had replaced the index.html, which was a 
link to the front-page.html of my web site with the default apache 
index.html.

Restored that by rm'ing the renamed copy of it, then cp'd the ~ version 
back to the real one, voila! Web page functions normally.

I haven't a clue what did that, I did not run anything that would have 
changed that while attempting to make it do an automatic conversion of 
an http access into an https access. So whatever did do it, I want to 
protect it from everything including me until such time as I remove the 
protections so I can edit it.

But I cannot make those links immutable, chattr won't let me. And 
apparently I can't remove the owners write perms.  So how can I freeze 
these solid until I restore write perms?

Is there a way to do this?

Thank you.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: how to force mysql to use the name of my machine instead of localhost

[Joe]

On Sun, 16 Apr 2017 20:45:56 +0100
Joe  wrote:

> On Sun, 16 Apr 2017 10:17:53 +0100
> Abdelkader Belahcene  wrote:
> 
> > *Thanks for reply and links*
> > 
> > 
> > *But I am sure, the problem is in mysql.*
> > *Look at this: *
> > 
> > *my count is lite@lite*
> > *and hostname  gives *
> > *lite@lite:/opt/lampp$ hostname*
> > *lite.umbb.dz <http://lite.umbb.dz>*
> > 
> > 
> > *bin/mysql*
> > 
> > *ERROR 1045 (28000): Acces s denied for user
> > 'lite'@'localhost' (using password: YES)*
> > 
> > *Here it tries to connect as 'lite'@'localhost', I am
> > not  'lite'@'localhost', but lite@lite*
> > *then  same thing as root, even if use -h option : *
> > 
> > *lite@lite:/opt/lampp$ bin/mysql -u root -h lite*
> > *ERROR 1045 (28000): Access denied for user
> > 'root'@'localhost' (using password: YES)*
> > *I tried  again, using the complete name, it adds localhost*
> > 
> > *lite@lite:/opt/lampp$ bin/mysql -u r...@lite.umbb.dz
> >  -p*
> > *Enter password: *
> > *ERROR 1045 (28000): Access denied for user 'r...@lite.umbb.dz
> > '@'localhost' (using password: YES)*
> > *Thanks a lot*  
> 
> As deloptes said, the issue is in mysql permissions. I said a week
> ago:
> 
> "If it is a problem with mysql account privileges, then change them.
> 
> Mysql user privileges depend on the name of the user and the name of
> the machine the user is connecting *from*. The name of the machine
> that mysql is running on is irrelevant, and would be needed only when
> setting up the connection on the remote machine using the mysql
> server's hostname."
> 
> Wordpress will have created a user in the mysql privileges table, with
> (theoretically) exactly the correct access permissions. But the user
> is named '@localhost'. The best way to proceed is to create
> another user with exactly the same privileges, and exactly the same


> '', but '@'. So for

Sorry, of course, that should be 'of the Wordpress server'. Not awake
this evening.

> example the new user is '@12.34.45.67'.
> 
> What are you using to administer mysql? If a GUI-based method, such as
> phpmyadmin, then open it on the whole installation, and look at the
> Privileges tab for the user list, where you will find the user that
> Wordpress has created. Then within the 'mysql' database, look at the
> 'db' table for detailed privileges. If you have no explicit mysql
> administration utility, then use the built-in command line mysql
> interface.
> 
> I am deliberately not being more specific, as if you are using mysql
> or any other database, even just as an accessory to another
> application, you cannot avoid acquiring at least a basic
> understanding of administration, if only to avoid problems like the
> one you currently have.
> 

Re: how to force mysql to use the name of my machine instead of localhost

[Joe]

On Sun, 16 Apr 2017 10:17:53 +0100
Abdelkader Belahcene  wrote:

> *Thanks for reply and links*
> 
> 
> *But I am sure, the problem is in mysql.*
> *Look at this: *
> 
> *my count is lite@lite*
> *and hostname  gives *
> *lite@lite:/opt/lampp$ hostname*
> *lite.umbb.dz <http://lite.umbb.dz>*
> 
> 
> *bin/mysql*
> 
> *ERROR 1045 (28000): Acces s denied for user 'lite'@'localhost' (using
> password: YES)*
> 
> *Here it tries to connect as 'lite'@'localhost', I am
> not  'lite'@'localhost', but lite@lite*
> *then  same thing as root, even if use -h option : *
> 
> *lite@lite:/opt/lampp$ bin/mysql -u root -h lite*
> *ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using
> password: YES)*
> *I tried  again, using the complete name, it adds localhost!!!!*
> 
> *lite@lite:/opt/lampp$ bin/mysql -u r...@lite.umbb.dz
>  -p*
> *Enter password: *
> *ERROR 1045 (28000): Access denied for user 'r...@lite.umbb.dz
> '@'localhost' (using password: YES)*
> *Thanks a lot*

As deloptes said, the issue is in mysql permissions. I said a week ago:

"If it is a problem with mysql account privileges, then change them.

Mysql user privileges depend on the name of the user and the name of
the machine the user is connecting *from*. The name of the machine that
mysql is running on is irrelevant, and would be needed only when
setting up the connection on the remote machine using the mysql server's
hostname."

Wordpress will have created a user in the mysql privileges table, with
(theoretically) exactly the correct access permissions. But the user is
named '@localhost'. The best way to proceed is to create another
user with exactly the same privileges, and exactly the same '', but
'@'. So for example the new
user is '@12.34.45.67'.

What are you using to administer mysql? If a GUI-based method, such as
phpmyadmin, then open it on the whole installation, and look at the
Privileges tab for the user list, where you will find the user that
Wordpress has created. Then within the 'mysql' database, look at the
'db' table for detailed privileges. If you have no explicit mysql
administration utility, then use the built-in command line mysql
interface.

I am deliberately not being more specific, as if you are using mysql or
any other database, even just as an accessory to another application,
you cannot avoid acquiring at least a basic understanding of
administration, if only to avoid problems like the one you currently
have.

-- 
Joe

Re: Re: how to force mysql to use the name of my machine instead of localhost

[deloptes]

Abdelkader Belahcene wrote:

> *Thanks for reply and links*
> 
> 
> *But I am sure, the problem is in mysql.*
> *Look at this: *
> 
> *my count is lite@lite*
> *and hostname  gives *
> *lite@lite:/opt/lampp$ hostname*
> *lite.umbb.dz <http://lite.umbb.dz>*
> 
> 
> *bin/mysql*
> 
> *ERROR 1045 (28000): Acces s denied for user 'lite'@'localhost' (using
> password: YES)*
> 
> *Here it tries to connect as 'lite'@'localhost', I am
> not  'lite'@'localhost', but lite@lite*
> *then  same thing as root, even if use -h option : *
> 
> *lite@lite:/opt/lampp$ bin/mysql -u root -h lite*
> *ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using
> password: YES)*
> *I tried  again, using the complete name, it adds localhost!!!!*
> 
> *lite@lite:/opt/lampp$ bin/mysql -u r...@lite.umbb.dz 
> -p*
> *Enter password: *
> *ERROR 1045 (28000): Access denied for user 'r...@lite.umbb.dz
> '@'localhost' (using password: YES)*
> *Thanks a lot*

There is a difference between using localhost and 127.0.0.1 (AFAIR).
Using localhost enforces using unix socket and not interface (tcp)
connection (AFAIR)

It all depends on giving the right permissions to your user. I think giving
root permissions to external interface is discouraged.
Having said that, what you need to do is give permission to the user to
connect properly

GRANT ALL PRIVILEGES ON * to ''@'127.0.0.1'
identified by  '';

bin/mysql -u  -p -h 127.0.0.1 

GRANT ALL PRIVILEGES ON * to ''@'lite.umbb.dz'
identified by  '';

bin/mysql -u  -p -h lite.umbb.dz 

it's not exactly rocket science

regards

Re: Re: how to force mysql to use the name of my machine instead of localhost

[Abdelkader Belahcene]

*Thanks for reply and links*


*But I am sure, the problem is in mysql.*
*Look at this: *

*my count is lite@lite*
*and hostname  gives *
*lite@lite:/opt/lampp$ hostname*
*lite.umbb.dz <http://lite.umbb.dz>*


*bin/mysql*

*ERROR 1045 (28000): Acces s denied for user 'lite'@'localhost' (using
password: YES)*

*Here it tries to connect as 'lite'@'localhost', I am
not  'lite'@'localhost', but lite@lite*
*then  same thing as root, even if use -h option : *

*lite@lite:/opt/lampp$ bin/mysql -u root -h lite*
*ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using
password: YES)*
*I tried  again, using the complete name, it adds localhost*

*lite@lite:/opt/lampp$ bin/mysql -u r...@lite.umbb.dz 
-p*
*Enter password: *
*ERROR 1045 (28000): Access denied for user 'r...@lite.umbb.dz
'@'localhost' (using password: YES)*
*Thanks a lot*

Re: Re: how to force mysql to use the name of my machine instead of localhost

[deloptes]

Abdelkader Belahcene wrote:

> thanks a lot for any idea

This has nothing to do with mysql or debian, but with wordpress. Please
refer the manual or subscribe to the wordpress list.
Perhaps someone else here may help you, but it would be OT IMO.

regards

Re: how to force mysql to use the name of my machine instead of localhost

[Richard Owlett]

On 04/11/2017 07:45 AM, Abdelkader Belahcene wrote:

Thanks for reply;
I give more details.
I install wordpress on my machine, it works fine on local,  I mean i if
write in the browser localhost/wordpress, it 's OK.

I can use myIP/worpress on a remote  machine to connect my server, It seems
working  fine, I get the main page,
BUT, CSS files are not read, I know that by prospecting the code source of
the page.

Wordpress store everything in database,  and so the name of the CSS file
for example, unfortunatly,  the path  used is full address of the file like
localhost/wordpress/blabla/style.css
here is the Big Problem

When the connection is local, no problem, since localhost is the host of
the server;

when the connection is  like :   http://myURL/wordpress,   we SHOULD FIND
the CSS file with  http://myURL/wordpress/blabla/style.css



 To solve the problem

   - either  we remove the absolute path for the files, and keep only  the
   relative part,  instead of storing  localhost/wordpress/blabla/style.css, we
   keep only wordpress/blabla/style.css
   - or we replace the localhost by the name of the machine or IP, that is
   what I want to do, I mean instead of storing in DB, localhost I tore the
   name of my machine like bela.enst.dz, the connetion w'll be done with
   this name and the problem is then solved

I used xampp to install apache, mysql and php. But the problem is the same
when I installed each element alone ( apache2, php, mysql)


when I used the command : localhost -f , I got the correct name
tmp$ hostname -f
bela.enst.dz

thanks a lot for any idea

Regards

bela



It depends to a degree on the details of how you installed WordPress 
[that is using apt-get/Synaptic/etc or downloading zip file from 
wordpress.org].
For that I suggest searching the Subject line of this group for about 
the last 5 years.


Some links that this Debian & WordPress newbie has found enlightening:
https://wiki.debian.org/WordPress

If apt-get/Synaptic/etc used for installation
http://localhost ["Apache2 Debian Default Page"]
/usr/share/doc/wordpress/README.Debian

HTH

Re: Re: how to force mysql to use the name of my machine instead of localhost

[Abdelkader Belahcene]

Thanks for reply;
I give more details.
I install wordpress on my machine, it works fine on local,  I mean i if
write in the browser localhost/wordpress, it 's OK.

I can use myIP/worpress on a remote  machine to connect my server, It seems
working  fine, I get the main page,
BUT, CSS files are not read, I know that by prospecting the code source of
the page.

Wordpress store everything in database,  and so the name of the CSS file
for example, unfortunatly,  the path  used is full address of the file like
localhost/wordpress/blabla/style.css
here is the Big Problem

When the connection is local, no problem, since localhost is the host of
the server;

when the connection is  like :   http://myURL/wordpress,   we SHOULD FIND
the CSS file with  http://myURL/wordpress/blabla/style.css



 To solve the problem

   - either  we remove the absolute path for the files, and keep only  the
   relative part,  instead of storing  localhost/wordpress/blabla/style.css, we
   keep only wordpress/blabla/style.css
   - or we replace the localhost by the name of the machine or IP, that is
   what I want to do, I mean instead of storing in DB, localhost I tore the
   name of my machine like bela.enst.dz, the connetion w'll be done with
   this name and the problem is then solved

I used xampp to install apache, mysql and php. But the problem is the same
when I installed each element alone ( apache2, php, mysql)


when I used the command : localhost -f , I got the correct name
tmp$ hostname -f
bela.enst.dz

thanks a lot for any idea

Regards

bela

Re: how to force mysql to use the name of my machine instead of localhost

[Joe]

On Mon, 10 Apr 2017 07:51:56 +0100
Abdelkader Belahcene  wrote:

> My  machine  has another name than localhost like lite.bela.umbb,
> when I install mysql, it always takes the the localhost as the name
> of the machine. this yields in a problem for me, when I use for
> example wordpress and I want a remote connection.  because the
> localhost stored in DB is irrelevant from a remote machine.
> 
> The question is : how to force mysql to use the name of my machine
> instead of localhost  for mysql server
> 

Mysql does not have or need a machine name. What problem are you having?
What are you trying to do and what error messages are you getting?

If it is a problem with mysql account privileges, then change them.

Mysql user privileges depend on the name of the user and the name of
the machine the user is connecting *from*. The name of the machine that
mysql is running on is irrelevant, and would be needed only when
setting up the connection on the remote machine using the mysql server's
hostname.

-- 
Joe

how to force mysql to use the name of my machine instead of localhost

[Abdelkader Belahcene]

My  machine  has another name than localhost like lite.bela.umbb,
when I install mysql, it always takes the the localhost as the name of the
machine. this yields in a problem for me, when I use for example wordpress
and I want a remote connection.  because the localhost stored in DB is
irrelevant from a remote machine.

The question is : how to force mysql to use the name of my machine instead
of localhost  for mysql server

Thanks a lot
Regards

Re: root@localhost mail not forwarding in Exim

[Jiangsu Kumquat]

Yes, this indeed was the problem!

For some reason the mail was being sent to "user" even though I had no user
named that.

Thanks a bunch! I have had this problem for quite a while and never could
figure out how to fix it.



On Thu, Mar 2, 2017 at 5:34 AM, Bonno Bloksma  wrote:

> Hi,
>
> >[]
> > so, if I want to use mail.example.com as my fqdn, and the old fqdn was
> something.else and r...@something.else was redirecting mail to
> m...@something.else ... then what do I need to change in Exim to make this
> happen?
>
> Is it maybe the aliases setting?
> Probably you edited the \etc\aliases file, it defines where to forward
> mail to. There will be a line like:
> root: me
> or
> root: m...@mail.example.com
> After saving the file it needs to be processed by the command
>  newaliases
> If you skip this file then mail to root will go to the old forward address
> and will fail if that no longer exists.
>
> Bonno Bloksma
>
>

RE: root@localhost mail not forwarding in Exim

[Bonno Bloksma]

Hi,
 
>[]
> so, if I want to use mail.example.com as my fqdn, and the old fqdn was 
> something.else and r...@something.else was redirecting mail to 
> m...@something.else ... then what do I need to change in Exim to make this 
> happen?

Is it maybe the aliases setting?
Probably you edited the \etc\aliases file, it defines where to forward mail to. 
There will be a line like:
root: me
or
root: m...@mail.example.com
After saving the file it needs to be processed by the command
 newaliases
If you skip this file then mail to root will go to the old forward address and 
will fail if that no longer exists.

Bonno Bloksma

Re: root@localhost mail not forwarding in Exim

[Jan-Peter Rühmann]

Have you tried sudo dpkg-reconfigure exim4-config

Which Settings you have there?

Am 01.03.2017 um 21:40 schrieb Jiangsu Kumquat:
> I changed my server name and fqdn and now the mail to root@localhost is 
> bouncing.
>
> I went into every file that had the old name and changed it to the new name 
> but it still
> doesn't work. I did "grep -r something.else /etc" to find all the files.
>
> so, if I want to use mail.example.com <http://mail.example.com> as my fqdn, 
> and the old
> fqdn was something.else and r...@something.else was redirecting mail to
> m...@something.else ... then what do I need to change in Exim to make this 
> happen?
>
> root@localhost is bouncing
> r...@mail.example.com <mailto:r...@mail.example.com> is bouncing
> m...@mail.example.com <mailto:m...@mail.example.com> is working
>
> /etc/mailname is this line:
> mail.example.com <http://mail.example.com>
>
> I would also like to be able to send mail to me@mail instead of 
> m...@mail.example.com
> <mailto:m...@mail.example.com> ... if this is possible.
>
> I did "grep -r something.else /etc" and changed all the files to the 
> mail.example.com
> <http://mail.example.com> name and then ran the "update-exim4.conf"
>
> if you reply, please CC me directly because it is hard to find messages in 
> this list
> because of the high volume.
>
> Thanks
Good Luck,
-- 

-=== Jan-Peter Rühmann & Kuma 
===-
 Gubkower Str.7   [  Tel.:  +49 (38205) 65484  ]   
jan-pe...@ruehmann.name
 18195 Prangendorf[  FAX:   +49 (38205) 65212  ]  
http://www.ruehmann.name
  [  Tel.:  +49 (38205) 65215  ]
  [  Mobil: +49 (162) 1316054  ]   
IT-Servicetechniker
Skype: jan-peter_ruehmann / ICQ: 288192920 / WhatsApp: 491621316054 / Twitter: 
@JPRuehmann
--
  Die Verwendung der Daten zu Werbezwecken ist verboten.

root@localhost mail not forwarding in Exim

[Jiangsu Kumquat]

I changed my server name and fqdn and now the mail to root@localhost is
bouncing.

I went into every file that had the old name and changed it to the new name
but it still doesn't work. I did "grep -r something.else /etc" to find all
the files.

so, if I want to use mail.example.com as my fqdn, and the old fqdn was
something.else and r...@something.else was redirecting mail to
m...@something.else ... then what do I need to change in Exim to make this
happen?

root@localhost is bouncing
r...@mail.example.com is bouncing
m...@mail.example.com is working

/etc/mailname is this line:
mail.example.com

I would also like to be able to send mail to me@mail instead of
m...@mail.example.com ... if this is possible.

I did "grep -r something.else /etc" and changed all the files to the
mail.example.com name and then ran the "update-exim4.conf"

if you reply, please CC me directly because it is hard to find messages in
this list because of the high volume.

Thanks

root@localhost mail not forwarding in Exim

[Jiangsu Kumquat]

I changed my server name and fqdn and now the mail to root@localhost is
bouncing.

I went into every file that had the old name and changed it to the new name
but it still doesn't work. I did "grep -r something.else /etc" to find all
the files.

so, if I want to use mail.example.com as my fqdn, and the old fqdn was
something.else and r...@something.else was redirecting mail to
m...@something.else ... then what do I need to change in Exim to make this
happen?

root@localhost is bouncing
r...@mail.example.com is bouncing
m...@mail.example.com is working

/etc/mailname is this line:
mail.example.com

I would also like to be able to send mail to me@mail instead of
m...@mail.example.com ... if this is possible.

I did "grep -r something.else /etc" and changed all the files to the
mail.example.com name and then ran the "update-exim4.conf"

if you reply, please CC me directly because it is hard to find messages in
this list because of the high volume.

Thanks

Re: sending authorized_keys to localhost from an account being created with adduser --disabled-password [was] Re: Need a tutorial

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Sep 23, 2016 at 04:41:00PM +, Stephan Beck wrote:
> Thank you very much, Tomás.

glad to help.

[...]

> But once my user's (in your terminology, steph's) public key is in the
> test account's authorized_keys file, user steph can login without
> superpowers, by presenting the private part of the key (well ssh-agent
> does it, if I understand things correctly), can't I?

That's how it's supposed to work (strictly speaking it doesn't present
the private part of the key, but just a *proof* that it is in control
of said private part, which the host account (test) can check).

The ssh-agent is just in charge of keeping unlocked private keys around
so that you only have to unlock them with your passphrase once per
session.

> My great mistake was to think that localhost, although being on the same
> machine, acts as a somewhat separated server and for that reason the
> public keys of all users have to be deposited physically, in a sort of
> directory structure within localhost (not in the user's directory),as it
> is the case on a remote server. But, as Greg made very clear, I'm
> already on the same machine. That was the conceptual mistake I made.

Exactly: the authorized_keys is a per-account thing, meaning "whoever
has the private key corresponding to *this* public key is allowed
to log in as me". Note that you even can restrict what commands are
allowed for each private key -- a "backup" user would only be allowed
to invoke a specific backup script at login, for example.

> > (the chown just in case authorized_keys didn't exist before).

[...]

> >   - creating the user's home directory from a prepared skeleton
> > already containing an "authorized_keys" as you need it
> 
> Ah, that would be fine, but I guess, this time it has to be the hard
> way, by typing, without prepared skeletons.

And it would only make sense if you go "industrial", as in "every user
on this box shall allow the user "backup" to invoke the per-user
backup script" or some such. I haven't needed that. Just a copy (or
an ssh-copy-id, if at he beginning the password access is available).

Regards
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlfmh/cACgkQBcgs9XrR2ka8lwCdEDbXPQ4Rhr24DmzstfbuzThD
LoIAn1BE33kb23NvEPuidLvc7NxAUnN5
=qpNT
-END PGP SIGNATURE-

Re: sending authorized_keys to localhost from an account being created with adduser --disabled-password [was] Re: Need a tutorial

[Stephan Beck]

Hi Greg and Tomás (one mail for all to limit the load of this thread on
the list) :-)

Greg Wooledge:
> On Fri, Sep 23, 2016 at 12:31:00PM +, Stephan Beck wrote:
[...]
> As user root:
> 
> stephan@hostname:~$ sudo mkdir -p ~test/.ssh
> stephan@hostname:~$ sudo sh -c 'cat ~stephan/.ssh/id_rsa.pub >> 
> ~test/.ssh/authorized_keys'
> stephan@hostname:~$ sudo chown test ~test/.ssh ~test/.ssh/authorized_keys
> stephan@hostname:~$ sudo chmod 700 ~test/.ssh
> stephan@hostname:~$ sudo chmod 600 ~test/.ssh/authorized_keys
I only had to perform command #2, and I ran it from a root shell.
I did the connection test, and it worked fine, but only after
an ssh restart.
Without it, the output was "Permission denied (publickey)"
Command #1 wasn't necessary as ~/test/.ssh had automatically been
created when running ssh-keygen. The permission had already been changed
to its secure values. At least, I came across dash's manpage while
trying to understand what the command actually does! Thanks a lot.

> to...@tuxteam.de:

> You cannot log into test without superpowers, but you have to modify its
> ~/.ssh/authorized_keys. That means you *need* superpowers. For example
> 
>   sudo -s # or similar
>   cat ~steph/.ssh/id_rsa.pub >> ~/test/.ssh/authorized_keys
>   chown test:test ~/test/.ssh/authorized_keys
>   exit

Ran command #2 from a root shell, did the connection test and it worked,
without having to restart ssh.

By the way, when I logged in via ssh (to *test*) now I was greeted by
"Last login [time of my connection attempt]from localhost". So, I
understand that I had logged into *test* via su - test  and then had
connected to *test* (from *test*) via localhost using ssh! Is this
interpretation correct?

Thanks to both of you again.

Stephan

Re: sending authorized_keys to localhost from an account being created with adduser --disabled-password [was] Re: Need a tutorial

[Stephan Beck]

Thank you very much, Tomás.

to...@tuxteam.de:
> On Fri, Sep 23, 2016 at 12:31:00PM +, Stephan Beck wrote:
>> Hi
>> to...@tuxteam.de:
>>> On Thu, Sep 22, 2016 at 03:35:00PM +, Stephan Beck wrote:
[...]
>> I have created a new user account with
>> adduser --disabled-password
>> What do I want to do?
>> I'd like to login to this account "test" from my normal user account by
>> ssh via pubkey authentication. My (normal) user account has its keys
>> generated and properly deposited on localhost. I logged into the account
>> "test" via su - test, creating a keypair. Fine.
> 
> Hang on: your new account (test( doesn't need a keypair. It's your regular
> account which needs one (and has one already). You want to log in *from*
> your regular account (let's call it "seph" for now) *to* test, right?

There are two things here: I had in mind to login from my user account
via ssh to the test account (just to be able to (completely) ssh inside
my machine [for training purposes] and, on the other hand, to ssh
towards the outside (see next sentence) as well. As to the "outside"
part, from the test account I want to login as client to a remote server
and because of that this test account needs a key pair, too. Yes, I know
it has to be deposited on that server, but, again, at the moment of this
thread I still am with (setting up) sshing inside my machine.
> 
> Then it's *steph* who has to have a keypair and *test* who has to have
> *steph*'s public key included in its ~/.ssh/authorized_keys:
> 
> 
>  *steph* *test*
>  .ssh/ .ssh/
>id_rsaauthorized_keys
>id_rsa.pub  ^
>\   |
> -- add ---´
> 
> 
> The background is that now *steph* can prove to *test* that he has the
> right secret key (without disclosing it).

OK, I got it, concerning sshing inside my machine. I got confused here
as I remembered that when I had a normal user account (with wheezy) and
a chroot environment (with debian sid installed) on the same machine I
could login from one to the other and vice versa via localhost using ssh
(well, if I remember correctly). It's different, for sure, but it
confused me.
> 
[...]
> You cannot log into test without superpowers, but you have to modify its
> ~/.ssh/authorized_keys. That means you *need* superpowers. For example
> 
>   sudo -s # or similar
>   cat ~steph/.ssh/id_rsa.pub >> ~/test/.ssh/authorized_keys
>   chown test:test ~/test/.ssh/authorized_keys
>   exit

But once my user's (in your terminology, steph's) public key is in the
test account's authorized_keys file, user steph can login without
superpowers, by presenting the private part of the key (well ssh-agent
does it, if I understand things correctly), can't I?
My great mistake was to think that localhost, although being on the same
machine, acts as a somewhat separated server and for that reason the
public keys of all users have to be deposited physically, in a sort of
directory structure within localhost (not in the user's directory),as it
is the case on a remote server. But, as Greg made very clear, I'm
already on the same machine. That was the conceptual mistake I made.
> 
> (the chown just in case authorized_keys didn't exist before).

Well, I have, i.e. had created an authorized_keys with the dd command.
It's there and it contains the public key.
> 
[,,,]
> Either you give this new user a password (temporarily) or you have to
> be able to write to its .ssh directory by other means. One of those
> means is by becoming root (as sketched above). There are others, like
> 
>   - adding yourself to this new user's group and making sure
> its ~/.ssh/authorized_keys is group writable (feels somewhat
> uncomfortable, though)

Uh! No way.
> 
>   - creating the user's home directory from a prepared skeleton
> already containing an "authorized_keys" as you need it

Ah, that would be fine, but I guess, this time it has to be the hard
way, by typing, without prepared skeletons.

I have to make a break and then I will try to get it done.

Thanks again.

Stephan

Re: sending authorized_keys to localhost from an account being created with adduser --disabled-password [was] Re: Need a tutorial

[Stephan Beck]

Stephan Beck:
> Thanks, Greg. I trimmed your message just to let you know that it does
> not work.


To be clear: after having found my solution I did your test (only the
test reproduced at the end of your message) and my solution does not work.

Thanks
Stephan

Re: sending authorized_keys to localhost from an account being created with adduser --disabled-password [was] Re: Need a tutorial

[Stephan Beck]

Thanks, Greg. I trimmed your message just to let you know that it does
not work.

Greg Wooledge:
> On Fri, Sep 23, 2016 at 12:31:00PM +, Stephan Beck wrote:

> As user stephan, to test that it works:
> 
> stephan@hostname:~$ ssh test@localhost id
> 
> If your username isn't actually "stephan", substitute accordingly.


me@mymachine:~$ sudo service ssh restart
me@mymachine:~$ ssh xb1158@localhost id
Permission denied (publickey).

I now will read carefully your (and the other messages sent in reply)
and will give a more thorough reply in a while. When I send my messages,
I send them and do not read the answers (arrived in the meantime) first,
so please do not think that I'm not interested in them.

Many thanks.

Stephan

Re: RESOLVED Re: sending authorized_keys to localhost from an account being created with adduser --disabled-password [was] Re: Need a tutorial

[Stephan Beck]

Hi,

Stephan Beck:
> Hi
> 
> Stephan Beck:
>> Hi
>>
>> to...@tuxteam.de:
>>> On Thu, Sep 22, 2016 at 03:35:00PM +, Stephan Beck wrote:
>>>
>>>
> 
>> How do I get this public key onto localhost?
> 
> No need to reply, I'll send the answer to document my solution within
> minutes.

Solution (feel free to comment)

#setting password authentication to no
root@mymachine nano /etc/ssh/sshd_config
root@mymachine:~# su - test
test@mymachine:~/.ssh$ chmod 600 authorized_keys
test@mymachine:~/.ssh$ dd if=id_rsa.pub of=authorized_keys
[test@mymachine:~/.ssh$ ssh localhost 'cat >> .ssh/authorized_keys']
test@mymachine:~/.ssh$ ssh -v test@localhost
[..many debug1 messages]
Enter passphrase for key /home/test/.ssh/id_rsa.pub':
debug1: Authentication succeeded (publickey).
Authenticated to localhost ([127.0.0.1]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessi...@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = de_DE.UTF-8

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
test@mymachine:~$


I think the one put in square brackets by me is redundant, isn't it? I
remember that the system hung for a moment and I did a CTRL-C to abort,
and proceeded with the next command, and then always used the -v option.
How did I find it? I remembered that somewhere in the manpages (not
sure) there was a reference to better make use of dd to copy, and I just
tried.

Have a nice weekend!

Stephan

Re: sending authorized_keys to localhost from an account being created with adduser --disabled-password [was] Re: Need a tutorial

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Sep 23, 2016 at 12:31:00PM +, Stephan Beck wrote:
> Hi
> 
> to...@tuxteam.de:
> > On Thu, Sep 22, 2016 at 03:35:00PM +, Stephan Beck wrote:
> > 
> > 
> >> to...@tuxteam.de:
> > 
> > [mumble]
> > 
> >>> This is the bird's view. Ask if you get stuck.
> > 
> > 
> >> Sorry, Tomas, it's not Gene, it's me who has a special question
> > 
> > No need to be sorry :-)
> 
> Fine! :-)
> > 
> > But I see you found a solution and other chimed in with sage advice.
> > 
> 
> Well, I have another one :-), a question, not a solution yet.
> 
> 
> I have created a new user account with
> adduser --disabled-password
> What do I want to do?
> I'd like to login to this account "test" from my normal user account by
> ssh via pubkey authentication. My (normal) user account has its keys
> generated and properly deposited on localhost. I logged into the account
> "test" via su - test, creating a keypair. Fine.

Hang on: your new account (test( doesn't need a keypair. It's your regular
account which needs one (and has one already). You want to log in *from*
your regular account (let's call it "seph" for now) *to* test, right?

Then it's *steph* who has to have a keypair and *test* who has to have
*steph*'s public key included in its ~/.ssh/authorized_keys:


 *steph* *test*
 .ssh/ .ssh/
   id_rsaauthorized_keys
   id_rsa.pub      ^
   \   |
-- add ---´


The background is that now *steph* can prove to *test* that he has the
right secret key (without disclosing it).

> How do I get this public key onto localhost?
> I mean, I can create an authorized_keys file manually, copying the
> public key into this authorized_keys file, but it's still in the user's
> directory where it has been generated, it needs to be sent (or get
> somehow) to localhost.
> 
> I have tried:
> test@mymachine cat .ssh/id_rsa.pub | ssh localhost 'cat >>
> .ssh/authorized_keys'

You cannot log into test without superpowers, but you have to modify its
~/.ssh/authorized_keys. That means you *need* superpowers. For example

  sudo -s # or similar
  cat ~steph/.ssh/id_rsa.pub >> ~/test/.ssh/authorized_keys
  chown test:test ~/test/.ssh/authorized_keys
  exit

(the chown just in case authorized_keys didn't exist before).

> But it's asking me a password. There is none.
> If I disable Password Authentication in sshd_config, and then try to
> send it to localhost, it fails with something like "denied access
> publickey required". No mystery at all, because this very public key is
> being sent to localhost in this very moment and can't be used in the
> same act for authentication purposes.
> 
> I've been reading a bunch of related docs in the man pages, debian wiki,
> in the exquisite and very readable Debian Administrator's Handbook by
> Raphael Mas and Raphaël Hertzog, and other linux ssh documentation. I
> can't find my specific use case and I'm stuck.

Either you give this new user a password (temporarily) or you have to
be able to write to its .ssh directory by other means. One of those
means is by becoming root (as sketched above). There are others, like

  - adding yourself to this new user's group and making sure
its ~/.ssh/authorized_keys is group writable (feels somewhat
uncomfortable, though)

  - creating the user's home directory from a prepared skeleton
already containing an "authorized_keys" as you need it

But all those methods need you being root at the machine where
*test* is created. You have to be root to create *test* in the
first place, though! So the proposed method above seems the
least intrusive to me.

Regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlflK5QACgkQBcgs9XrR2kb0AACeO1pPTe9vm31zAzvWVhNdH/Wb
EqUAn1Ftz5STEPa2JHhXScrq7nrYbpPa
=cIRd
-END PGP SIGNATURE-

RESOLVED Re: sending authorized_keys to localhost from an account being created with adduser --disabled-password [was] Re: Need a tutorial

[Stephan Beck]

Hi

Stephan Beck:
> Hi
> 
> to...@tuxteam.de:
>> On Thu, Sep 22, 2016 at 03:35:00PM +, Stephan Beck wrote:
>>
>>

> How do I get this public key onto localhost?

No need to reply, I'll send the answer to document my solution within
minutes.


Stephan

Re: sending authorized_keys to localhost from an account being created with adduser --disabled-password [was] Re: Need a tutorial

[Greg Wooledge]

On Fri, Sep 23, 2016 at 12:31:00PM +, Stephan Beck wrote:
> I have created a new user account with
> adduser --disabled-password
> What do I want to do?
> I'd like to login to this account "test" from my normal user account by
> ssh via pubkey authentication. My (normal) user account has its keys
> generated and properly deposited on localhost. I logged into the account
> "test" via su - test, creating a keypair. Fine.

Typically, you want to create the keypair as the user on the machine which
will be the client.  This way the private key never has to be touched,
moved, looked at, etc.

So, you want to ssh
FROM user "stephan" on this machine
TO   user "test"on this (same) machine

The private key needs to reside in ~stephan/.ssh/ where the client will
see it.

The public key needs to be concatenated into ~test/.ssh/authorized_keys
where the server will see it.

> How do I get this public key onto localhost?

Trick question.  You are already on the correct machine.  You just need
to have everything in the correct places (files/directories) with the
correct ownerships.

> I mean, I can create an authorized_keys file manually, copying the
> public key into this authorized_keys file, but it's still in the user's
> directory where it has been generated, it needs to be sent (or get
> somehow) to localhost.

As user stephan:

stephan@hostname:~$ ssh-keygen

As user root:

stephan@hostname:~$ sudo mkdir -p ~test/.ssh
stephan@hostname:~$ sudo sh -c 'cat ~stephan/.ssh/id_rsa.pub >> 
~test/.ssh/authorized_keys'
stephan@hostname:~$ sudo chown test ~test/.ssh ~test/.ssh/authorized_keys
stephan@hostname:~$ sudo chmod 700 ~test/.ssh
stephan@hostname:~$ sudo chmod 600 ~test/.ssh/authorized_keys

(Of course, if you prefer you could just obtain a root shell and then run
all of the commands without sudo.)

As user stephan, to test that it works:

stephan@hostname:~$ ssh test@localhost id

If your username isn't actually "stephan", substitute accordingly.

sending authorized_keys to localhost from an account being created with adduser --disabled-password [was] Re: Need a tutorial

[Stephan Beck]

Hi

to...@tuxteam.de:
> On Thu, Sep 22, 2016 at 03:35:00PM +, Stephan Beck wrote:
> 
> 
>> to...@tuxteam.de:
> 
> [mumble]
> 
>>> This is the bird's view. Ask if you get stuck.
> 
> 
>> Sorry, Tomas, it's not Gene, it's me who has a special question
> 
> No need to be sorry :-)

Fine! :-)
> 
> But I see you found a solution and other chimed in with sage advice.
> 

Well, I have another one :-), a question, not a solution yet.


I have created a new user account with
adduser --disabled-password
What do I want to do?
I'd like to login to this account "test" from my normal user account by
ssh via pubkey authentication. My (normal) user account has its keys
generated and properly deposited on localhost. I logged into the account
"test" via su - test, creating a keypair. Fine.

How do I get this public key onto localhost?
I mean, I can create an authorized_keys file manually, copying the
public key into this authorized_keys file, but it's still in the user's
directory where it has been generated, it needs to be sent (or get
somehow) to localhost.

I have tried:
test@mymachine cat .ssh/id_rsa.pub | ssh localhost 'cat >>
.ssh/authorized_keys'

But it's asking me a password. There is none.
If I disable Password Authentication in sshd_config, and then try to
send it to localhost, it fails with something like "denied access
publickey required". No mystery at all, because this very public key is
being sent to localhost in this very moment and can't be used in the
same act for authentication purposes.

I've been reading a bunch of related docs in the man pages, debian wiki,
in the exquisite and very readable Debian Administrator's Handbook by
Raphael Mas and Raphaël Hertzog, and other linux ssh documentation. I
can't find my specific use case and I'm stuck.

Any hints (also from other people) welcome.

Stephan

on Debian-Jessie

Re: No localhost - I'm stumped [SOLVED]

[John]

On 27/08/14, Reco (recovery...@gmail.com) wrote:
> On Tue, 26 Aug 2014 23:12:05 +0100
> "Karl E. Jorgensen"  wrote:
> 
> > > > 4) sysctl --system
> > > sysctl --system
> > > * Applying /etc/sysctl.d/99-sysctl.conf ...
> > > net.ipv4.icmp_echo_ignore_all = 0
> > > net.ipv4.icmp_echo_ignore_broadcasts = 0
> > 
> > These caught my eye: Ignore all ICMP ? That would stop ping
> > (a.k.a. ICMP echo) from working, wouldn't it?
> 
> In this case 0 means 'false'. I.e. 
> 
> net.ipv4.icmp_echo_ignore_broadcasts = 0
> 
> equals to 
> 
> 'do not ignore icmp echo broadcasts'.

Karl, Reco,

That did it.  "ping localhost" now works.  For the record, here are the results 
of systemctl --system:
* Applying /etc/sysctl.conf ...
net.ipv4.icmp_echo_ignore_all = 0
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.ip_forward = 1
net.ipv4.conf.all.secure_redirects = 1
vm.swappiness = 1
vm.vfs_cache_pressure = 50

I am truly grateful for the good help I have received.  Many, many thaqnks.

-- 
johnrchamp...@wowway.com

GPG key 1024D/99421A63 2005-01-05
EE51 79E9 F244 D734 A012 1CEC 7813 9FE9 9942 1A63
gpg --keyserver subkeys.pgp.net --recv-keys 99421A63


signature.asc
Description: Digital signature

Re: No localhost - I'm stumped

[John]

On 26/08/14, Karl E. Jorgensen (k...@jorgensen.org.uk) wrote:
> > sysctl --system
> > * Applying /etc/sysctl.d/99-sysctl.conf ...
> > net.ipv4.icmp_echo_ignore_all = 0
> > net.ipv4.icmp_echo_ignore_broadcasts = 0
> 
> These caught my eye: Ignore all ICMP ? That would stop ping
> (a.k.a. ICMP echo) from working, wouldn't it?
 
Thanks for the suggestion, but according to 
/usr/src/linux/Documentation/networking/ip-sysctl.txt

icmp_echo_ignore_all - BOOLEAN
If set non-zero, then the kernel will ignore all ICMP ECHO
requests sent to it.
Default: 0

icmp_echo_ignore_broadcasts - BOOLEAN
If set non-zero, then the kernel will ignore all ICMP ECHO and
TIMESTAMP requests sent to it via broadcast/multicast.
Default: 1


-- 
johnrchamp...@wowway.com

GPG key 1024D/99421A63 2005-01-05
EE51 79E9 F244 D734 A012 1CEC 7813 9FE9 9942 1A63
gpg --keyserver subkeys.pgp.net --recv-keys 99421A63


signature.asc
Description: Digital signature

Re: No localhost - I'm stumped

[Reco]

 Hi.

On Wed, 27 Aug 2014 00:27:24 +0100
Brian  wrote:

> On Wed 27 Aug 2014 at 02:01:14 +0400, Reco wrote:
> 
> > And, by the way, ipv6 has nothing to do with this problem, although the
> > output of ipv6 routing tables looks abnormal to me too.
> 
> You could very well be correct. But, should the OP decide to continue
> without ipv6, he may find systemd to be unforgiving.

Probably you're right. Still, unless systemd generated those iptables
rules - it has nothing to do with this problem.

REco


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140827111026.38bf923394080736cae38...@gmail.com

Re: No localhost - I'm stumped

[Reco]

 Hi.

On Tue, 26 Aug 2014 23:12:05 +0100
"Karl E. Jorgensen"  wrote:

> > > 4) sysctl --system
> > sysctl --system
> > * Applying /etc/sysctl.d/99-sysctl.conf ...
> > net.ipv4.icmp_echo_ignore_all = 0
> > net.ipv4.icmp_echo_ignore_broadcasts = 0
> 
> These caught my eye: Ignore all ICMP ? That would stop ping
> (a.k.a. ICMP echo) from working, wouldn't it?

In this case 0 means 'false'. I.e. 

net.ipv4.icmp_echo_ignore_broadcasts = 0

equals to 

'do not ignore icmp echo broadcasts'.

Reco


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140827110919.7d117c4e64e6515bfd7ee...@gmail.com

Re: No localhost - I'm stumped

[Brian]

On Wed 27 Aug 2014 at 02:01:14 +0400, Reco wrote:

> And, by the way, ipv6 has nothing to do with this problem, although the
> output of ipv6 routing tables looks abnormal to me too.

You could very well be correct. But, should the OP decide to continue
without ipv6, he may find systemd to be unforgiving.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/27082014002343.9fb75b78b...@desktop.copernicus.demon.co.uk

Re: No localhost - I'm stumped

[Karl E. Jorgensen]

Hi

On Tue, Aug 26, 2014 at 03:50:25PM -0400, John wrote:
> On 25/08/14, Reco (recovery...@gmail.com) wrote:
> 
> > Date: Mon, 25 Aug 2014 22:13:41 +0400
> > From: Reco 
> > To: debian-user@lists.debian.org
> > Subject: Re: No localhost - I'm stumped
> > X-Spam-Status: No, score=-11.2 required=4.0 tests=DKIM_SIGNED,DKIM_VALID,
> >  DKIM_VALID_AU,DKIM_VERIFIED,FREEMAIL_FROM,LDOSUBSCRIBER,LDO_WHITELIST,
> >  T_TO_NO_BRKTS_FREEMAIL autolearn=unavailable version=3.3.2
> > 
> >  Hi.
> > 
> > On Mon, 25 Aug 2014 12:09:59 -0400
> > John  wrote:
> > 
> > > ...  But alas, nothing from it solved my problem. ...
> >
> > Probably won't do you any good, since you have a basic kernel facility
> > (ip routing) in a broken state.
> > 
> > Can you please post the output of (run it all as root):
> 
> I've separated the various items with  -- to make them easier to find.
> 
> > 1) iptables-save
> iptables-save
> # Generated by iptables-save v1.4.21 on Tue Aug 26 15:41:11 2014
> *mangle
> :PREROUTING ACCEPT [19424:11674255]
> :INPUT ACCEPT [18400:11319703]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [17345:4202761]
> :POSTROUTING ACCEPT [17393:4208427]
> COMMIT
> # Completed on Tue Aug 26 15:41:11 2014
> # Generated by iptables-save v1.4.21 on Tue Aug 26 15:41:11 2014
> *nat
> :PREROUTING ACCEPT [1166:401489]
> :INPUT ACCEPT [0:0]
> :OUTPUT ACCEPT [2108:130276]
> :POSTROUTING ACCEPT [0:0]
> -A POSTROUTING -j MASQUERADE
> COMMIT
> # Completed on Tue Aug 26 15:41:11 2014
> # Generated by iptables-save v1.4.21 on Tue Aug 26 15:41:11 2014
> *filter
> :INPUT DROP [0:0]
> :FORWARD DROP [0:0]
> :OUTPUT ACCEPT [17315:4187744]
> -A INPUT -s 127.0.0.0/8 -d 127.0.0.0/8 -i lo -j ACCEPT
> -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
> -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT
> -A INPUT -p tcp -m tcp --dport 25 -m state --state NEW -j ACCEPT
> -A INPUT -m state --state INVALID,NEW -j DROP
> -A FORWARD -j REJECT --reject-with icmp-port-unreachable
> COMMIT

iptables look OK to me - although I find it "cleaner" to have:

 -A INPUT -i lo -j ACCEPT

but I guess it doesn't make any difference.

> > 2) strace ping -c2 localhost

snipped  output - it looks OK to my cursory glances..


> > 4) sysctl --system
> sysctl --system
> * Applying /etc/sysctl.d/99-sysctl.conf ...
> net.ipv4.icmp_echo_ignore_all = 0
> net.ipv4.icmp_echo_ignore_broadcasts = 0

These caught my eye: Ignore all ICMP ? That would stop ping
(a.k.a. ICMP echo) from working, wouldn't it?

-- 
Karl E. Jorgensen


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140826221205.GA18500@hawking

Re: No localhost - I'm stumped

[Reco]

 Hi.

On Tue, 26 Aug 2014 15:50:25 -0400
John  wrote:

> -A POSTROUTING -j MASQUERADE

This is the source of your trouble. You're redirecting packets intended
to go via loopback to nat with this rule, which is obviously wrong.
I suggest you to try this rule instead:

iptables -t nat -A POSTROUTING ! -o lo -j MASQUERADE


And, by the way, ipv6 has nothing to do with this problem, although the
output of ipv6 routing tables looks abnormal to me too.

Reco


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140827020114.d73b2523f5bec856d5bde...@gmail.com

Re: No localhost - I'm stumped

[Brian]

On Tue 26 Aug 2014 at 15:50:25 -0400, John wrote:

> On 25/08/14, Reco (recovery...@gmail.com) wrote:
> > 
> > 3) strace ping6 -c2 ip6-localhost
> 
> I've left this one out, since I recompiled the kernel without ip6
> support.  "ping6 localhost" had produced a result and my thinking was
> to force whatever it was to use ip4 again.  Was that a mistake

Yes, a big one. You may as well view ipv6 as mandatory with systemd.
Which is why I queried why it was missing in another post.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/26082014213614.721667827...@desktop.copernicus.demon.co.uk

Re: No localhost - I'm stumped

[John]

On 25/08/14, Reco (recovery...@gmail.com) wrote:

> Date: Mon, 25 Aug 2014 22:13:41 +0400
> From: Reco 
> To: debian-user@lists.debian.org
> Subject: Re: No localhost - I'm stumped
> X-Spam-Status: No, score=-11.2 required=4.0 tests=DKIM_SIGNED,DKIM_VALID,
>  DKIM_VALID_AU,DKIM_VERIFIED,FREEMAIL_FROM,LDOSUBSCRIBER,LDO_WHITELIST,
>  T_TO_NO_BRKTS_FREEMAIL autolearn=unavailable version=3.3.2
> 
>  Hi.
> 
> On Mon, 25 Aug 2014 12:09:59 -0400
> John  wrote:
> 
> > ...  But alas, nothing from it solved my problem. ...
>
> Probably won't do you any good, since you have a basic kernel facility
> (ip routing) in a broken state.
> 
> Can you please post the output of (run it all as root):

I've separated the various items with  -- to make them easier to find.

> 1) iptables-save
iptables-save
# Generated by iptables-save v1.4.21 on Tue Aug 26 15:41:11 2014
*mangle
:PREROUTING ACCEPT [19424:11674255]
:INPUT ACCEPT [18400:11319703]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [17345:4202761]
:POSTROUTING ACCEPT [17393:4208427]
COMMIT
# Completed on Tue Aug 26 15:41:11 2014
# Generated by iptables-save v1.4.21 on Tue Aug 26 15:41:11 2014
*nat
:PREROUTING ACCEPT [1166:401489]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [2108:130276]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -j MASQUERADE
COMMIT
# Completed on Tue Aug 26 15:41:11 2014
# Generated by iptables-save v1.4.21 on Tue Aug 26 15:41:11 2014
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [17315:4187744]
-A INPUT -s 127.0.0.0/8 -d 127.0.0.0/8 -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 25 -m state --state NEW -j ACCEPT
-A INPUT -m state --state INVALID,NEW -j DROP
-A FORWARD -j REJECT --reject-with icmp-port-unreachable
COMMIT
# Completed on Tue Aug 26 15:41:11 2014
--------
> 
> 2) strace ping -c2 localhost
 strace ping -c2 localhost
execve("/bin/ping", ["ping", "-c2", "localhost"], [/* 36 vars */]) = 0
brk(0)  = 0xe6d000
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fddf9e77000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=103146, ...}) = 0
mmap(NULL, 103146, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fddf9e5d000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libcap.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p\26\0\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=1, ...}) = 0
mmap(NULL, 2114224, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7fddf9a54000
mprotect(0x7fddf9a58000, 2093056, PROT_NONE) = 0
mmap(0x7fddf9c57000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7fddf9c57000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\34\2\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1729984, ...}) = 0
mmap(NULL, 3836480, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7fddf96ab000
mprotect(0x7fddf984a000, 2097152, PROT_NONE) = 0
mmap(0x7fddf9a4a000, 24576, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x19f000) = 0x7fddf9a4a000
mmap(0x7fddf9a5, 14912, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fddf9a5
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libattr.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240\24\0\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=18672, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fddf9e5c000
mmap(NULL, 2113896, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7fddf94a6000
mprotect(0x7fddf94aa000, 2093056, PROT_NONE) = 0
mmap(0x7fddf96a9000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7fddf96a9000
close(3)= 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fddf9e5b000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 

Re: No localhost - I'm stumped

[Reco]

 Hi.

On Mon, 25 Aug 2014 12:09:59 -0400
John  wrote:

> Thanks for the help and the link; it's useful.  But alas, nothing from it s=
> olved my problem.  I think next I'll try reinstalling stuff -- cups, hplip,=
>  anything else that comes to mind -- and see if I blunder into a fix.

Probably won't do you any good, since you have a basic kernel facility
(ip routing) in a broken state.


> Still, it would be nice to _understand_ ...

Can you please post the output of (run it all as root):

1) iptables-save

2) strace ping -c2 localhost

3) strace ping6 -c2 ip6-localhost

4) sysctl --system

5) ip ro l

6) ip -6 ro l


Reco


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140825221341.437a812f29d257d0bf796...@gmail.com

Re: No localhost - I'm stumped

[Catalin Soare]

On Aug 25, 2014 7:30 PM, "John"  wrote:
>
> On 24/08/14, Curt (cu...@free.fr) wrote:
> > On 2014-08-24, John  wrote:
> > >
> > > I've tried everything I can think of, and hints regarding what to try
next
> > > would be higholy welcome.
> >
> > Some things to try here:
> >
> >
http://unix.stackexchange.com/questions/26487/can-ping-any-hosts-but-localhost-whats-wrong
>
> Thanks for the help and the link; it's useful.  But alas, nothing from it
s=
> olved my problem.  I think next I'll try reinstalling stuff -- cups,
hplip,=
>  anything else that comes to mind -- and see if I blunder into a fix.
>
> Still, it would be nice to _understand_ ...
>
> --
> johnrchamp...@wowway.com
> 
> GPG key 1024D/99421A63 2005-01-05
> EE51 79E9 F244 D734 A012 1CEC 7813 9FE9 9942 1A63
> gpg --keyserver subkeys.pgp.net --recv-keys 99421A63

Hello there,

This may not be much of an answer to your problem but anyway:

On windoze systems, when you don't get a reply from 127.0.0.1, you've got a
problem with your tcp/ip stack network driver.
You should then try to reset it (on windoze you will have to do it with
netsh and then reconfigure the nic) or/and reinstall the nic driver.

You may also try reinstalling packages like the ones you mentioned, since
there are just so many dependencies, but keep your backups close and warm.

Cheers!

Re: No localhost - I'm stumped

[John]

On 24/08/14, Curt (cu...@free.fr) wrote:
> On 2014-08-24, John  wrote:
> >
> > I've tried everything I can think of, and hints regarding what to try next
> > would be higholy welcome.
> 
> Some things to try here:
> 
> http://unix.stackexchange.com/questions/26487/can-ping-any-hosts-but-localhost-whats-wrong

Thanks for the help and the link; it's useful.  But alas, nothing from it s=
olved my problem.  I think next I'll try reinstalling stuff -- cups, hplip,=
 anything else that comes to mind -- and see if I blunder into a fix.

Still, it would be nice to _understand_ ...

-- 
johnrchamp...@wowway.com

GPG key 1024D/99421A63 2005-01-05
EE51 79E9 F244 D734 A012 1CEC 7813 9FE9 9942 1A63
gpg --keyserver subkeys.pgp.net --recv-keys 99421A63


signature.asc
Description: Digital signature

Re: No localhost - I'm stumped

[Brian]

On Sun 24 Aug 2014 at 13:43:25 -0400, John wrote:

> For some days now, localhost has not responded to anything.  I've tried
> everything, and am stumped.  Here are a few indications:
> 
> netstat -an |grep 631
> tcp0  0 127.0.0.1:631   0.0.0.0:*   LISTEN
> tcp0  1 127.0.0.1:57813 127.0.0.1:631   SYN_SENT
> tcp0  0 127.0.0.1:631   127.0.0.1:57780 FIN_WAIT2
> tcp0  1 127.0.0.1:57811 127.0.0.1:631   SYN_SENT
> tcp0  1 127.0.0.1:57817 127.0.0.1:631   SYN_SENT
> tcp0  1 127.0.0.1:57816 127.0.0.1:631   SYN_SENT
> tcp0  1 127.0.0.1:57812 127.0.0.1:631   SYN_SENT
> tcp0  1 127.0.0.1:57815 127.0.0.1:631   SYN_SENT
> tcp1  0 127.0.0.1:57780 127.0.0.1:631   CLOSE_WAIT
> udp0  0 0.0.0.0:631 0.0.0.0:*

I'd be a bit bothered by there being no line like

   tcp600 ::1:631   :::*LISTEN

in this output.

> I've replaced /etc/hosts with a known-to-work version.

May we see this version, please.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/24082014211900.7e6747a3a...@desktop.copernicus.demon.co.uk

Re: No localhost - I'm stumped

[Curt]

On 2014-08-24, John  wrote:
>
>
> I've tried everything I can think of, and hints regarding what to try next
> would be higholy welcome.
>

Some things to try here:

http://unix.stackexchange.com/questions/26487/can-ping-any-hosts-but-localhost-whats-wrong


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/slrnlvkb40.1v4.cu...@einstein.electron.org

No localhost - I'm stumped

[John]

For some days now, localhost has not responded to anything.  I've tried 
everything, and am stumped.  Here are a few indications:

ifconfig shows lo is working:
loLink encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:65536  Metric:1
  RX packets:87 errors:0 dropped:0 overruns:0 frame:0
  TX packets:87 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:17213 (16.8 KiB)  TX bytes:17213 (16.8 KiB)

ping gets no response:
--- 127.0.0.1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 1999ms

netstat -an |grep 631
tcp0  0 127.0.0.1:631   0.0.0.0:*   LISTEN
tcp0  1 127.0.0.1:57813 127.0.0.1:631   SYN_SENT
tcp0  0 127.0.0.1:631   127.0.0.1:57780 FIN_WAIT2
tcp0  1 127.0.0.1:57811 127.0.0.1:631   SYN_SENT
tcp0  1 127.0.0.1:57817 127.0.0.1:631   SYN_SENT
tcp0  1 127.0.0.1:57816 127.0.0.1:631   SYN_SENT
tcp0  1 127.0.0.1:57812 127.0.0.1:631   SYN_SENT
tcp0  1 127.0.0.1:57815 127.0.0.1:631   SYN_SENT
tcp1  0 127.0.0.1:57780 127.0.0.1:631   CLOSE_WAIT
udp0  0 0.0.0.0:631 0.0.0.0:*

I've replaced /etc/hosts with a known-to-work version.

systemctl status cups show cups and cups.socket are running:
Aug 24 13:29:34 ctoo systemd[1]: Started CUPS Printing Service.
Aug 24 13:29:34 ctoo systemd[1]: Starting CUPS Printing Service Sockets.
Aug 24 13:29:34 ctoo systemd[1]: Listening on CUPS Printing Service Sockets.


I've tried everything I can think of, and hints regarding what to try next 
would be higholy welcome.

-- 
johnrchamp...@wowway.com

GPG key 1024D/99421A63 2005-01-05
EE51 79E9 F244 D734 A012 1CEC 7813 9FE9 9942 1A63
gpg --keyserver subkeys.pgp.net --recv-keys 99421A63


signature.asc
Description: Digital signature

Re: MPD on localhost won't work if there's no Wifi!?

[Bob Proulx]

Brian wrote:
> Bob Proulx wrote:
> > Brian wrote:
> > > or, if the domain name is left blank,
> > >   127.0.1.1   foo
> > > would be seen.
> > 
> > Doesn't it create an entry like this?  I will need to test it in order
> > to see what it creates in that case.
> >   127.0.1.1   foo.localdomain  foo
> > I will try it later and report back.  :-)
> 
> Please do.

You are correct.  I just tried it.  If the domain name is left blank
(something I usually don't do) then what you say is what happens.

  127.0.1.1   foo

Bob


signature.asc
Description: Digital signature

Re: MPD on localhost won't work if there's no Wifi!?

[Brian]

On Fri 13 Jun 2014 at 15:28:48 -0600, Bob Proulx wrote:

> Brian wrote:
> > Bob Proulx wrote:
> > > Brian wrote:
> > > > True. What do think about the lack of '127.0.1.1 localhost' in 
> 
> It is the "127.0.1.1 localhost" to which I was disagreeing.  That
> would be unusual.  It is still the loopback device so off the top of
> my head I think everything should still work okay.  But for best
> compatibilty I think 127.0.0.1 should always be localhost the reverse.

There is quite extensive history attached to the use of 127.0.1.1 in
/etc/hosts. Parts of the most recent discussion is at:

   https://lists.debian.org/debian-devel/2013/08/msg00095.html

and

   https://lists.debian.org/debian-devel/2013/08/msg00151.html
 
> If the actual hostname of the system is "localhost" then there is no
> need for any other entry other than the 127.0.0.1 entry and the
> 127.0.1.1 entry isn't needed at all.  (Now I need to verify that the
> installer doesn't add it in that case.  I recall that it does not.)

Teresa had /etc/hostname as "localhost". If I do the same d-i writes my
127.0.1.1 line as

   127.0.1.1localhost.lan   localhost.

during an expert install.

> Now that you mentioned the case of what happens if DHCP returns
> something unusual I think I would need to check.  But I think it still
> behaves the same regardless.  I don't think anything the DHCP server
> returns is going to affect this.  But I can't say for certain without
> looking and testing.  It might.

Not that I have any skills at all in understanding source code but
netcfg has

   dhcp.c:if (netcfg_get_hostname(client, "netcfg/dhcp_hostname", 
interface->dhcp_hostname, 0))
   dhcp.c: * If the netcfg/hostname preseed value is set use 
that
   dhcp.c: * otherwise default to the hostname returned via 
DHCP, if any,
   dhcp.c: * otherwise to the requested DHCP hostname
   dhcp.c: * otherwise to the hostname found in DNS for the IP 
address
 
> I am more interested now in what happens in a CD#1 install completely
> offline.

The hostname will be either the default ("debian") or whatever is
preseeded with hostname= on the command line. I wouldn't expect there to
be a domain name.

   dhcp.c:/* We don't have a domain name yet, but we need to write 
out the
   dhcp.c: * Default to the domain name returned via DHCP, if any
   dhcp.c:di_debug("Reading domain name returned via DHCP");
   dhcp.c:di_debug("DHCP domain name is '%s'", domain);
   netcfg-common.c: * Verify that the domain name (or FQDN) conforms to RFC 
1123 s2.1, and
   netcfg-common.c:} else { /* assume we have a valid domain name 
given */
   netcfg-common.c:/* Global var 'domain' is holding a temporary 
domain name,
 
> > Suppose the server doesn't provide a domain name. Then she will have
> > 
> >127.0.1.1   foo
> > 
> > because there is no need for an alias.
> 
> That is a good question!  But doesn't the installer ask you for a
> domain name specifically?  I believe it does.  Therefore the user
> should always enter a domain name.  But if they don't then I don't
> know what the installer puts there by default.

The default is the domain name returned via DHCP. Blanking the field
results in no domain name.
 
> I _thought_ the installer put the special "localdomain" string there
> in the case that the user left it empty.  Because sometimes there
> isn't any reasonable thing to put there.  In that case it creates a
> consistent and valid configuration using localhost and localdomain.
> That way applications that require a domain name to be present will
> have a constructed one that will work even if bogus.  (As I recall
> this predates RFC 2606 which created a .localhost domain.)
> 
> The idea is that some applications such as Postfix for one example,
> along with others, that really want a fully qualified hostname can
> have a fully consistent configuration by using localhost.localdomain.
> The localdomain part is a created construct.  But on an unconnected
> system everything can map consistently and everything can work
> regardless.

I don't pretend to understand this in its entirety, but from netcfg's
changelog:

   [ Thomas Hood ]
   * If there is no permanent IP address with which the system hostname
   (i.e., that which is returned by the "hostname" command) can be
   associated in /etc/hosts then associate it with address 127.0.1.1
   rather than 127.0.0.1.  Associating the system hostname with the
   latter had the unwanted effect of making 'localhost.localdomain'
   the canonical hostna

Re: MPD on localhost won't work if there's no Wifi!?

[Bob Proulx]

Brian wrote:
> Bob Proulx wrote:
> > Brian wrote:
> > > True. What do think about the lack of '127.0.1.1 localhost' in 

It is the "127.0.1.1 localhost" to which I was disagreeing.  That
would be unusual.  It is still the loopback device so off the top of
my head I think everything should still work okay.  But for best
compatibilty I think 127.0.0.1 should always be localhost the reverse.

If the actual hostname of the system is "localhost" then there is no
need for any other entry other than the 127.0.0.1 entry and the
127.0.1.1 entry isn't needed at all.  (Now I need to verify that the
installer doesn't add it in that case.  I recall that it does not.)

> > > etc/hosts? Squeeze and Wheezy installs would both put this line in.
> > 
> > Process check!  I think you have mixed up the two cases.  Since a long
> > time now Debian installs a /etc/hosts file that will look like this:
> > 
> >   127.0.0.1   localhost
> 
> Agreed.
> 
> >   127.0.1.1   foo.example.comfoo
> 
> Agreed - sort of :).
> 
> A line in /etc/hosts has the form
> 
>IP_address canonical_hostname [aliases...]
> 
> aliases are optional and the second field will always be the canonical
> hostname.

So far so good! :-)

> What a Debian install puts for 127.0.1.1 depends on how the install took
> place. If the user just uses 'install' d-i can get /etc/hostname and the
> domain name from whatever dhcp server is being used.

Hmm...  I hadn't thought about an odd DHCP configuration creating
something unusual there.  I am still suspicious...  I think it works
the same regardless.

>127.0.1.1   foo.example.comfoo
> 
> is what the user could get.

Since I usually install things in what I consider a "normal" state I
completely agree.  That is what you would get.

Now that you mentioned the case of what happens if DHCP returns
something unusual I think I would need to check.  But I think it still
behaves the same regardless.  I don't think anything the DHCP server
returns is going to affect this.  But I can't say for certain without
looking and testing.  It might.

I am more interested now in what happens in a CD#1 install completely
offline.

> Suppose the server doesn't provide a domain name. Then she will have
> 
>127.0.1.1   foo
> 
> because there is no need for an alias.

That is a good question!  But doesn't the installer ask you for a
domain name specifically?  I believe it does.  Therefore the user
should always enter a domain name.  But if they don't then I don't
know what the installer puts there by default.

I _thought_ the installer put the special "localdomain" string there
in the case that the user left it empty.  Because sometimes there
isn't any reasonable thing to put there.  In that case it creates a
consistent and valid configuration using localhost and localdomain.
That way applications that require a domain name to be present will
have a constructed one that will work even if bogus.  (As I recall
this predates RFC 2606 which created a .localhost domain.)

The idea is that some applications such as Postfix for one example,
along with others, that really want a fully qualified hostname can
have a fully consistent configuration by using localhost.localdomain.
The localdomain part is a created construct.  But on an unconnected
system everything can map consistently and everything can work
regardless.

> For an expert install the hostname and domain name can be specified, so
> either
> 
>   127.0.1.1   foo.example.comfoo
> 
> or, if the domain name is left blank,
> 
>   127.0.1.1   foo
> 
> would be seen.

Doesn't it create an entry like this?  I will need to test it in order
to see what it creates in that case.

  127.0.1.1   foo.localdomain  foo

I will try it later and report back.  :-)

> With preseeding the hostname can be be preseeded but not the domain
> name. So I'd expect both the previous two variants to be possible.

The domain *can* be preseeded.  I do that all of the time.  Really!
On the install command line.  For me usually through the PXE network
boot syslinux interface.

  hostname=junk domain=proulx.com

> I do not think we are in serious disagreement.

Sometimes we disagree but it is never serious.  I always look forward
to your postings Brian.  They are always high quality helpful
postings.  I enjoy our discussions.

Bob


signature.asc
Description: Digital signature

Re: MPD on localhost won't work if there's no Wifi!?

[Brian]

On Thu 12 Jun 2014 at 16:23:37 -0600, Bob Proulx wrote:

> Brian wrote:
> > Tom H wrote:
> > > Brian wrote:
> > > > Teresa e Junior wrote:
> > > >> $ cat /etc/hostname
> > > >> localhost
> > ...
> > True. What do think about the lack of '127.0.1.1 localhost' in 
> > etc/hosts? Squeeze and Wheezy installs would both put this line in.
> 
> Process check!  I think you have mixed up the two cases.  Since a long
> time now Debian installs a /etc/hosts file that will look like this:
> 
>   127.0.0.1   localhost

Agreed.

>   127.0.1.1   foo.example.comfoo

Agreed - sort of :).

A line in /etc/hosts has the form

   IP_address canonical_hostname [aliases...]

aliases are optional and the second field will always be the canonical
hostname.

What a Debian install puts for 127.0.1.1 depends on how the install took
place. If the user just uses 'install' d-i can get /etc/hostname and the
domain name from whatever dhcp server is being used.

   127.0.1.1   foo.example.comfoo

is what the user could get.

Suppose the server doesn't provide a domain name. Then she will have

   127.0.1.1   foo

because there is no need for an alias.

For an expert install the hostname and domain name can be specified, so
either

  127.0.1.1   foo.example.comfoo

or, if the domain name is left blank,

  127.0.1.1   foo

would be seen.

With preseeding the hostname can be be preseeded but not the domain
name. So I'd expect both the previous two variants to be possible.

I do not think we are in serious disagreement.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140613191542.gx17...@copernicus.demon.co.uk

Re: MPD on localhost won't work if there's no Wifi!?

[Bob Proulx]

Brian wrote:
> Tom H wrote:
> > Brian wrote:
> > > Teresa e Junior wrote:
> > >> $ cat /etc/hostname
> > >> localhost
> ...
> True. What do think about the lack of '127.0.1.1 localhost' in 
> etc/hosts? Squeeze and Wheezy installs would both put this line in.

Process check!  I think you have mixed up the two cases.  Since a long
time now Debian installs a /etc/hosts file that will look like this:

  127.0.0.1   localhost
  127.0.1.1   foo.example.com    foo

That way 127.0.0.1 maps to localhost and localhost maps to 127.0.0.1
and this is always independent of whether networking is up or down.
That is just the default and of course may be locally modified.  I
think it is a good default.  I do have some special cases that need
this to be adjusted otherwise but good as a general purpose default.

Additionally the hostname always uses the loopback device.  Again this
allows applications to work using the hostname regardless of the state
of other network devices.

Bob


signature.asc
Description: Digital signature

Re: MPD on localhost won't work if there's no Wifi!?

[Teresa e Junior]

On Tue, 10 Jun 2014 08:22:58 +0300, Andrei POPESCU wrote:

As far as I can tell mpc is low-level enough to not care about what
Network Manager advertises. I'm suspecting it does have something to do
with DNS, so I'd suggest you pick a name for your machine and make sure
you adjust your configs as follows (assuming your machine's name is
'mpdserver'):

/etc/hostname:
mpdserver

/etc/hosts:
127.0.0.1   localhost
127.0.1.1   mpdserver

(you can also use the lan IP here if it is fixed and enabling the IPv6
entries could also help)

mpd.conf:
bind_to_address "localhost"


After making all these changes exactly as you have mentioned, I wouldn't 
see that error anymore. But because I'm curious, I decided to 
investigate what was the culprit, and I found that leaving 
bind_to_address as "localhost" and enabling the IPv6 entries in 
/etc/hosts was enough. Then I commented the entries again in /etc/hosts 
and immediately mpc stopped working.



If you make all these changes it's probably a good idea to reboot. If
mpc still can't connect please post the output of:

 getent hosts localhost
 getent hosts mpdserver # or whatever you named it
 netstat -plant | grep mpd

with and without Network Manager running.


The old getent output, from when it was not working:
$ getent hosts localhost
127.0.0.1   localhost

The old getent output, from when it was working:
$ getent hosts localhost
127.0.0.1   localhost
And sometimes:
::1     localhost

The new getent output:
$ getent hosts localhost
::1 localhost ip6-localhost ip6-loopback

Always netstat has shown this:
$ netstat -plant | grep mpd
tcp 0 0 127.0.0.1:6600  0.0.0.0:*LISTEN 4062/mpd
tcp60 0 ::1:6600:::* LISTEN 4062/mpd

Thanks really a lot to everyone for this!
Teresa and Junior


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/5396e7ae.3060...@gmail.com

Re: MPD on localhost won't work if there's no Wifi!?

[Andrei POPESCU]

On Lu, 09 iun 14, 23:05:43, Teresa e Junior wrote:
> I believe it's got something to do with NetworkManager, because mpc started
> working as soon as I run:
> $ sudo service network-manager stop
> 
> And then I run this, and while trying to connect, or later if connecting
> fails, mpc won't work again:
> $ sudo service network-manager start
> 
> The version of NetworkManager installed is 0.9.4.0-10 on wheezy. I believe
> NM kind of advertises to the system if there is a connection available. As
> an example, if configured as such, Claws Mail will only check for emails
> based on information passed by NetworkManager.

As far as I can tell mpc is low-level enough to not care about what 
Network Manager advertises. I'm suspecting it does have something to do 
with DNS, so I'd suggest you pick a name for your machine and make sure 
you adjust your configs as follows (assuming your machine's name is 
'mpdserver'):

/etc/hostname:
mpdserver

/etc/hosts:
127.0.0.1   localhost
127.0.1.1   mpdserver

(you can also use the lan IP here if it is fixed and enabling the IPv6 
entries could also help)

mpd.conf:
bind_to_address "localhost"

If you make all these changes it's probably a good idea to reboot. If 
mpc still can't connect please post the output of:

getent hosts localhost
getent hosts mpdserver # or whatever you named it
netstat -plant | grep mpd

with and without Network Manager running.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: MPD on localhost won't work if there's no Wifi!?

[Teresa e Junior]

I believe it's got something to do with NetworkManager, because mpc 
started working as soon as I run:

$ sudo service network-manager stop

And then I run this, and while trying to connect, or later if connecting 
fails, mpc won't work again:

$ sudo service network-manager start

The version of NetworkManager installed is 0.9.4.0-10 on wheezy. I 
believe NM kind of advertises to the system if there is a connection 
available. As an example, if configured as such, Claws Mail will only 
check for emails based on information passed by NetworkManager.


On Mon, 9 Jun 2014 10:46:12 -0400, Tom H wrote:

For testing only!: Does mpc run without the network being up if you
add "127.0.2.2 r.usyncapp.com." (Trying to determine whether mpc needs
something from that host or whether it just needs to resolve the
hostname.)


r.usyncapp.com. has something to do with Bittorrent Sync, but disabling 
btsync or adding that line to /etc/hosts won't make any difference.


On Mon, 9 Jun 2014 10:46:12 -0400, Tom H wrote:
> If the OP's problem has to do with dns resolution and the OP's using
> NM, then the lack of a "127.0.1.1" entry is probably a problem because
> NM uses dnsmasq by default and "/etc/resolv.conf" is then set to
> "127.0.1.1".

I had a look, and network-manager recommends dnsmasq-base, which I don't 
have installed.


Thanks to all for your help!
Teresa and Junior


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/53967607.4010...@gmail.com