Re: Perdida de gigas...

[Camaleón]

El 2020-09-22 a las 18:55 -0500, Aristobulo_Pinzón escribió:

> Por que razón al formatear como ext4 una partición de 445 Gigas se rebaja 
> hasta 386.2 gigas, solamente?
> Se utilizo el formato por defecto sin ningún parametro personal.

¿El disco está vacío? ~60 GiB menos parece excesivo. 

Manda la salida de «df -h». 

¿Con qué herramienta le has dado formato?

En este mensaje de los foros de ArchLinux hablan del tema, quizá te 
pueda servir, a efectos prácticos:

ext4: missing space (not journal / reserved blocks related)
https://bbs.archlinux.org/viewtopic.php?id=119445

Y otro artículo más técnico:

Linux sysadmins want to know: Where did my disk space go?
https://www.redhat.com/sysadmin/disk-space

Saludos,

-- 
Camaleón 

Re: dhcp bridge for virtual machines using KVM

[Fabien Roucaute]

Le 22/09/2020 à 22:57, James Allsopp a écrit :
> 
> 
> On Tue, 22 Sep 2020 at 17:58, Fabien Roucaute  > wrote:
> 
> Le 22/09/2020 à 18:50, James Allsopp a écrit :
> >
> > I've tried that but I get the same result.
> > Thanks
> > James
> >
> 
> You need to answer to the mailing-list email address, not mine.
> If it still doesn't work, we need more information, like the result of
> the following commands (you should modify the public IP that appears in
> if it's the case)
> 'ip a'
> 'iptables-save'
> 'brctl show'
> 
> 
> Here's ip a
>  ip a
> 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN
> group default qlen 1000
>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>     inet 127.0.0.1/8  scope host lo
>        valid_lft forever preferred_lft forever
>     inet6 ::1/128 scope host
>        valid_lft forever preferred_lft forever
> 2: eth0:  mtu 1500 qdisc pfifo_fast
> state DOWN group default qlen 1000
>     link/ether 00:1d:7d:0d:2a:9f brd ff:ff:ff:ff:ff:ff
> 3: eth1:  mtu 1500 qdisc pfifo_fast
> master br0 state UP group default qlen 1000
>     link/ether 00:1d:7d:0d:2a:9d brd ff:ff:ff:ff:ff:ff
> 4: wlan0:  mtu 1500 qdisc noqueue state
> UP group default qlen 1000
>     link/ether b4:ee:b4:84:37:2a brd ff:ff:ff:ff:ff:ff
>     inet 192.168.1.174/24  brd 192.168.1.255
> scope global dynamic noprefixroute wlan0
>        valid_lft 27656sec preferred_lft 27656sec
>     inet6 fde6:4511:f54::a55/128 scope global noprefixroute
>        valid_lft forever preferred_lft forever
>     inet6 fde6:4511:f54:0:f195:8361:215d:5f17/64 scope global noprefixroute
>        valid_lft forever preferred_lft forever
>     inet6 fe80::4bf0:ca57:25f0:ed7f/64 scope link noprefixroute
>        valid_lft forever preferred_lft forever
> 5: br0:  mtu 1500 qdisc noqueue state
> UP group default qlen 1000
>     link/ether 00:1d:7d:0d:2a:9d brd ff:ff:ff:ff:ff:ff
>     inet 192.168.1.206/24  brd 192.168.1.255
> scope global dynamic br0
>        valid_lft 27655sec preferred_lft 27655sec
>     inet6 fde6:4511:f54:0:21d:7dff:fe0d:2a9d/64 scope global dynamic
> mngtmpaddr
>        valid_lft forever preferred_lft forever
>     inet6 fe80::21d:7dff:fe0d:2a9d/64 scope link
>        valid_lft forever preferred_lft forever
> 6: docker0:  mtu 1500 qdisc noqueue
> state DOWN group default
>     link/ether 02:42:12:5f:1a:5e brd ff:ff:ff:ff:ff:ff
>     inet 172.17.0.1/16  brd 172.17.255.255 scope
> global docker0
>        valid_lft forever preferred_lft forever
> 8: vnet0:  mtu 1500 qdisc pfifo_fast
> master br0 state UNKNOWN group default qlen 1000
>     link/ether fe:54:00:8a:6e:57 brd ff:ff:ff:ff:ff:ff
>     inet6 fe80::fc54:ff:fe8a:6e57/64 scope link
>        valid_lft forever preferred_lft forever
> 
> 
> Here's iptables -L
>  iptables -L
> Chain INPUT (policy ACCEPT)
> target     prot opt source               destination        
> 
> Chain FORWARD (policy DROP)
> target     prot opt source               destination        
> DOCKER-USER  all  --  anywhere             anywhere            
> DOCKER-ISOLATION-STAGE-1  all  --  anywhere             anywhere            
> ACCEPT     all  --  anywhere             anywhere             ctstate
> RELATED,ESTABLISHED
> DOCKER     all  --  anywhere             anywhere            
> ACCEPT     all  --  anywhere             anywhere            
> ACCEPT     all  --  anywhere             anywhere            
> 
> Chain OUTPUT (policy ACCEPT)
> target     prot opt source               destination        
> 
> Chain DOCKER (1 references)
> target     prot opt source               destination        
> 
> Chain DOCKER-ISOLATION-STAGE-1 (1 references)
> target     prot opt source               destination        
> DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere            
> RETURN     all  --  anywhere             anywhere            
> 
> Chain DOCKER-ISOLATION-STAGE-2 (1 references)
> target     prot opt source               destination        
> DROP       all  --  anywhere             anywhere            
> RETURN     all  --  anywhere             anywhere            
> 
> Chain DOCKER-USER (1 references)
> target     prot opt source               destination        
> RETURN     all  --  anywhere             anywhere     
> 
> and brctl show
> 
> bridge name     bridge id               STP enabled     interfaces
> br0             8000.001d7d0d2a9d       no              eth1
>                                                         vnet0
> docker0         8000.0242125f1a5e       no
> 
> Thanks!
> James

I forgot to ask for the routing table, could you post the result of 'ip
r' ? Otherwise, can I ask why you think you need a Wifi connection and
wired one but assigned to them ip addresses that are in the same subnet?
Because you can access the host and the VMs on different IPs with only
the wired NIC.

Re: Perdida de gigas...

[Paynalton]

El mar., 22 sept. 2020 a las 19:12, Aristobulo_Pinzón (<
ristobulopin...@gmail.com>) escribió:

> Buenas amables colaboradores.
>
> Por que razón al formatear como ext4 una partición de 445 Gigas se rebaja
> hasta 386.2 gigas, solamente?
> Se utilizo el formato por defecto sin ningún parametro personal.
> Saludos.
>
>
Nunca he visto que reduzca tanto un ext4, pero ocupa parte del espacio para
el respaldo del journal.

Re: ssh session times out annoyingly fast, why?

[Gary Dale]

On 2020-09-21 19:38, Britton Kerin wrote:

I'm using ssh from a debian box to a rasberry pi (sorta debian also :).

For some reason ssh sessions seem to time out pretty quickly.  I've
tried setting ClientAliveInterval and ClientAliveCountMax and also
ServerAliveInterval  and ServerAliveCountMax, but it doesn't seem to
make any difference.  Is there some other setting somewhere that
affects this?

Thanks,
Britton

My money is on a network issue. Lately my connection to a remote server 
seems to lock up quickly while I have a stable connection to a local 
server. Both servers are running Debian/Stable and I haven't fiddled 
with the ssh settings in a long time.

Re: weird behaviour of quotes in bash variable assignments

[Gary Dale]

On 2020-09-22 01:48, Andrei POPESCU wrote:

On Lu, 21 sep 20, 17:22:26, Gary Dale wrote:

I presented the line that failed, copied and pasted from the Konsole
session. What more do you want, other than to complain?

In such cases it is best to attach[1] the smallest complete[2] script
demonstrating the behaviour.

Based on the information provided so far it is highly likely the issue
was caused by some detail you omitted because you decided it is not
relevant.

[1] as demonstrated, copy-pasting can alter content
[2] as discussed, the shebang line can make a big difference

Kind regards,
Andrei


Your first point makes it impossible for me to present anything because 
this list doesn't (AFAIK) allow attachments. I can only present a 
copy-pasted example.


Your second point would assume that I'm using a non-standard shebang. I 
use #!/bin/sh unless I need something that is only available in bash 
(can't recall a case of that). Moreover, the consensus seems to be that 
if there was an error on the shebang line, the default shell would be used.


The smallest complete script then is

report=”/root/clamscan-report”
echo $report

but as I explained, that works on one server but not the other. Hence my 
question wasn't "what's wrong with this line" but rather "how do I 
change the behaviour". I'm not expecting anyone else to be able to 
reproduce the problem because I can't even do it except on the one server.


And to do that, I didn't even need the shebang line. I could enter the 
line at the command prompt then echo it and see the same result. Since 
it wasn't the shebang line, and didn't even require being in a script, 
why should I have included the shebang line?

Perdida de gigas...

[Aristobulo_Pinzón]

Buenas amables colaboradores.

Por que razón al formatear como ext4 una partición de 445 Gigas se rebaja hasta 
386.2 gigas, solamente?
Se utilizo el formato por defecto sin ningún parametro personal.
Saludos.

Re: weird behaviour of quotes in dash variable assignments

[Gary Dale]

On 2020-09-22 00:25, David Christensen wrote:

On 2020-09-21 18:04, Gary Dale wrote:

The two servers are for different customers. I would not want to 
create a tunnel between them. Instead I have my normal ssh tunnels to 
each server from my workstation. However the script is only readable 
by root while my tunnels are for my non-root account. While I could 
copy the file to my non-root account (while root), chown it, copy it 
to my workstation then to the other server, where I'd move it to 
/root, that's a lot more work than cat, copy, paste, save.


Again, the method I used should not have created any changes in the 
script that would affect its operation. And to date I've seen no 
indication that it did. I still don't know why the script was leaving 
the quotes in nor why it started working.


You might want to consider ssh-agent and SSH agent forwarding. These 
allow you to access your version control server over SSH from remote 
hosts by using your workstation credentials; no credentials required 
on the remote host:



https://dev.to/levivm/how-to-use-ssh-and-ssh-agent-forwarding-more-secure-ssh-2c32 




David

I'm not sure that does anything for me. I would need to create a "root" 
key to get access to the file, which is something I refuse to do.


Right now the ssh tunnel requires a key on the remote server and there 
are no root keys so even if someone gains access, they still don't have 
root access.


There are other tools that work better for pushing things to multiple 
servers but all of these tools assume you are doing it often enough or 
to enough machines to make it worthwhile. That's not my situation.

(solved) Re: ssh fingerprint mismatch for one single client

[Beco]

> Yes. Given the data you've provided, I retract my first hunch: it seems
> your student is seeing a different host:
>
>  - either DNS resolves to a different IP address -- then you'd see
>different IP addresses for your server as viewed from your student's
>workstation wrt the "rest of the world
>
>  - or routing sends your student to a different host (claiming the
>same IP address, that stinks ;-)
>
> Traceroute might help in the second case. Besides, you wouldn't see your
> student's access attempts in your server logs -- after all, he's knocking
> at another door.
>
> Cheers
>  - t
>


Dear Linuxers,

I just want to close this issue by thanking everyone who chipped in with
help and attempts to solve the problem

Unfortunately the mistery will go on, because my student solve the problem
by  changing his  ISP server.

He told that the problem was solved immediately, as we predict and tested
(via mobile and the neighbor's internet).

So, I cannot run any more tests, and I'll stay curious about what really
happened.

My bet: the "homebrew ISP" has a DNS problem.

Thanks.

Dr. Bèco





-- 
Dr Beco
A.I. researcher

"I know you think you understand what you thought I said but I'm not sure
you realize that what you heard is not what I meant" -- Alan Greenspan

GPG Key: https://pgp.mit.edu/pks/lookup?op=vindex=0x5A107A425102382A
Creation date: pgp.mit.edu ID as of 2014-11-09

Essa mensagem é destinada exclusivamente ao seu destinatário e pode conter
informações confidenciais, protegidas por sigilo profissional, direitos
autorais reservados, ou cuja divulgação seja proibida por lei. O uso não
autorizado de tais informações é proibido e está sujeito às penalidades
cabíveis.

This message is intended exclusively for its addressee and may contain
information that is confidential and protected by a professional privilege,
reserved copyright, or whose disclosure is prohibited by law. Unauthorized
use of such information is prohibited and subject to applicable penalties.

Re: linux isn't robust enough to handle bad sector??

[David Christensen]

On 2020-09-22 06:04, David Wright wrote:

On Tue 22 Sep 2020 at 10:06:46 (+), Long Wind wrote:

 On Tuesday, September 22, 2020, 2:45:30 AM EDT, David Christensen 
 wrote:



https://www.seagate.com/support/downloads/seatools/



it has only exe file, no iso file, you need Windows



You picked the wrong file to download. Go back to the
https://www.seagate.com/support/downloads/seatools/
page and read the text in the corner of the browser
window as the mouse hovers over the big blobs.
The second blob down goes to
https://www.seagate.com/support/downloads/seatools/seatools-legacy-support-master/
Here you will find graphical and text versions that
are bootable ISOs which run under FreeDOS:
https://www.seagate.com/files/www-content/support-content/downloads/seatools/_shared/downloads/SeaToolsDOS223ALL.ISO
and
https://www.seagate.com/files/www-content/support-content/downloads/seatools/_shared/downloads/SeaToolsDOS112.ISO
with instructions:
https://www.seagate.com/files/staticfiles/support/downloads/seatools/seatools-dos-guide.pdf
Download those.


Thank you for finding the old ISO versions (I recall using those in the 
past).  Given the age of the OP's computers, there is a god chance he 
has an optical drive.  Hopefully, it works.



David

SSH agent forwarding (was: weird behaviour of quotes in dash variable assignments)

[David Christensen]

On 2020-09-22 13:05, Gary Dale wrote:

On 2020-09-22 00:25, David Christensen wrote:

On 2020-09-21 18:04, Gary Dale wrote:

The two servers are for different customers. I would not want to 
create a tunnel between them. Instead I have my normal ssh tunnels to 
each server from my workstation. However the script is only readable 
by root while my tunnels are for my non-root account. While I could 
copy the file to my non-root account (while root), chown it, copy it 
to my workstation then to the other server, where I'd move it to 
/root, that's a lot more work than cat, copy, paste, save.


Again, the method I used should not have created any changes in the 
script that would affect its operation. And to date I've seen no 
indication that it did. I still don't know why the script was leaving 
the quotes in nor why it started working.


You might want to consider ssh-agent and SSH agent forwarding. These 
allow you to access your version control server over SSH from remote 
hosts by using your workstation credentials; no credentials required 
on the remote host:



https://dev.to/levivm/how-to-use-ssh-and-ssh-agent-forwarding-more-secure-ssh-2c32 




David

I'm not sure that does anything for me. I would need to create a "root" 
key to get access to the file, which is something I refuse to do.


This book is relevant:

https://mwl.io/nonfiction/tools#ssh


Here is my workstation.  I will demonstrate SSH agent forwarding using 
it both as the workstation and as the server:


2020-09-22 14:57:40 root@tinkywinky ~
# cat /etc/debian_version ; uname -a
9.13
Linux tinkywinky 4.9.0-13-amd64 #1 SMP Debian 4.9.228-1 (2020-07-05) 
x86_64 GNU/Linux



The workstation and the server must have at least one SSH host key pair. 
 The Debian installer creates three:


2020-09-22 14:49:56 dpchrist@tinkywinky ~
$ ls -1 /etc/ssh/ssh_host*key*
/etc/ssh/ssh_host_ecdsa_key
/etc/ssh/ssh_host_ecdsa_key.pub
/etc/ssh/ssh_host_ed25519_key
/etc/ssh/ssh_host_ed25519_key.pub
/etc/ssh/ssh_host_rsa_key
/etc/ssh/ssh_host_rsa_key.pub


The workstation user account must have at least one SSH user key pair:

2020-09-22 14:51:21 dpchrist@tinkywinky ~
$ ls -1 .ssh/id_rsa*
.ssh/id_rsa
.ssh/id_rsa.pub


No root account key pair is required on the server.


The server root account authorized_keys file must contain the 
workstation user account public key(s).  Append the contents of 
~/.ssh/id_rsa.pub from the workstation to /root/.ssh/authorized_keys on 
the server.



Agent forwarding must be enabled on the workstation:

2020-09-22 14:55:20 dpchrist@tinkywinky ~
$ egrep ^ForwardAgent /etc/ssh/ssh_config
ForwardAgent yes


Root public key authentication must be enabled on the server (it is 
enabled by default on my Debian machines):


2020-09-22 14:56:32 dpchrist@tinkywinky ~
$ egrep PermitRootLogin /etc/ssh/sshd_config | head -n 1
PermitRootLogin prohibit-password


Restart sshd on the server, if required:

2020-09-22 14:57:35 root@tinkywinky ~
# service sshd restart


Start a terminal on the workstation.  Start ssh-agent(1) using your 
shell of choice (with any required options or arguments):


2020-09-22 15:01:31 dpchrist@tinkywinky ~
$ ssh-agent bash -l


Add your user account key pair to the SSH agent:

2020-09-22 15:01:34 dpchrist@tinkywinky ~
$ ssh-add
Enter passphrase for /home/dpchrist/.ssh/id_rsa:
Identity added: /home/dpchrist/.ssh/id_rsa (/home/dpchrist/.ssh/id_rsa)


Log in as root on the server via public key authentication (no 
passphrase required):


2020-09-22 15:02:09 dpchrist@tinkywinky ~
$ ssh root@localhost
Linux tinkywinky 4.9.0-13-amd64 #1 SMP Debian 4.9.228-1 (2020-07-05) x86_64
Last login: Tue Sep 22 14:57:35 2020 from ::1

2020-09-22 15:02:35 root@tinkywinky ~
#


Now I can use my workstation user account credentials on the remote 
machine just like I would use them locally (via agent forwarding; no 
passphrase required):


2020-09-22 15:02:35 root@tinkywinky ~
# cvs diff


Optionally, you can disable password authentication on the server and 
restart sshd.  The only way to log in will be via the console or via SSH 
public key authentication:


2020-09-22 15:04:40 root@tinkywinky ~
# grep Password /etc/ssh/sshd_config
PasswordAuthentication no

2020-09-22 15:22:05 root@tinkywinky ~
# service sshd restart


Right now the ssh tunnel requires a key on the remote server 


I don't use SSH tunnels (yet).  The SSH agent forwarding technique I 
demonstrated above does not require any user or root keys on the server.



and there 
are no root keys so even if someone gains access, they still don't have 
root access.


If someone gains access to what?


There are other tools that work better for pushing things to multiple 
servers but all of these tools assume you are doing it often enough or 
to enough machines to make it worthwhile. That's not my situation.


Ansible, Puppet, etc., seem like overkill for my needs.  I have not used 
them.



I use ssh-agent(1), scp(1), and ssh(1) interactively, and I wrote shell 
scripts, 

Re: weird behaviour of quotes in dash variable assignments

[Gary Dale]

On 2020-09-22 09:29, David Wright wrote:

On Mon 21 Sep 2020 at 20:50:29 (-0400), Gary Dale wrote:

On 2020-09-21 10:30, David Wright wrote:

On Mon 21 Sep 2020 at 08:18:52 (-0400), Greg Wooledge wrote:

On Mon, Sep 21, 2020 at 07:55:45AM -0400, Cindy Sue Causey wrote:

'…' and "…" are known as neutral, vertical, straight, typewriter,
dumb, or ASCII quotation marks.

‘…’ and “…” are known as typographic, curly, curved, book, or smart
quotation marks.

Yes.  This is one of the possible causes for the behavior the OP was
reporting.  But if this is true, then it reveals that they were lying
when they claimed that the scripts were the same on both servers.

[…]

To beat a dead horse some more, if *this* was the OP's problem, then they
told multiple lies about it.  They did not paste the actual failing line
from the failing script (probably retyped it instead), and they did not
ACTUALLY COMPARE the two scripts to see whether they were different,
instead simply ASSUMING that the two scripts were identical, even though
they very clearly weren't.

An actual troubleshooting would have done something like using md5sum
on the script on each machine, and pasting the md5sum commands (including
the full script pathname) and their output to the mailing list.  Openness.

Or, hell, even "ls -l /full/pathname" would probably have revealed that
the scripts were not the same SIZE.  That would also have shown immediately
that the scripts were not "the same".

I think we should apply Hanlon's razor rather than saying the OP lied.
After all, "compare" means diff or cmp to us, whereas many might just
use their eyeballs. And we all know that authors are the worst people
to check their own work. Proof-reading is a special skill.

Even their fix is poorly described. Did they just type the quotes back
in with an editor, in which case there's no guarantee that the scripts
are identical between machines, or did they transfer a working script
to the failing machine? The best line is save until last: "I certainly
didn't update anything on either server...". Well, yes, that's
*precisely* what you did: you updated the script.

   ↑↑

You are taking my quote out of context. I didn't change anything on
the server to make the script start working. I updated the script to



see if it would work after trying Greg's test. There were no program
or setting updates on the server, and certainly nothing that updated
dash. This is Debian/Stable we're talking about, after all.

Sorry, I thought you wrote that on Sunday afternoon, "I fixed it by
removing the quotes on the one server but now the scripts are
different between the two servers, which isn't what I want."
Then on Sunday evening, you wrote "When I retried my script with the
quotes, it started working."

The general opinion is that the script was faulty, probably in the
quotes used. The narrative says that you removed the quotes, and
later put them back. It seems fair to suggest that the quotes you
put back were not the same ones that you removed. They were replaced
in the same location, but you didn't put the old (removed) quotes
into a little two-character file, so that you could put precisely
the same ones back into the script, did you?
I thought about that but then there would be no way I could demonstrate 
it other than what I did - post the offending line via cut & paste, a 
method people have been arguing can change the quotes.



Since it is a file server, there probably were changes to the files on
its shares, but I'd hardly count that as an "update". Similarly, it
was running cron jobs for backups and virus scans (unsuccessfully) but
again I wouldn't call those "updates".

Nor I. No, I'm only talking about your script. Does it bear any
relation to the one posted in your blog? The first line (after
the shebang) of the one in the blog is the same line that's under
discussion here, and has curly quotes. I can't parse the second
line's curly quotes, and the fourth line uses an n-dash for a
hyphen *though the other hyphens are ok). The fifth line uses
curly single-quotes. More curly quotes follow.

I don't see any cause for our wasting time pondering on dash
without your posting an MWE that unambiguously demonstrates a
problem.
Yes, that's the script - copy-pasted from the working server then with 
the e-mail addresses changed (they are actually parameters to the 
working script, but why complicate things when explaining a basic 
script). As you noted, it has changed things - hopefully not to the 
point that people won't be able to make it work. I haven't found a way 
to stop Wordpress from doing the substitution but I note the raw text is 
still correct (once you remove the html).

Re: dhcp bridge for virtual machines using KVM

[Lucas Castro]

On 9/22/20 5:54 PM, James Allsopp wrote:



On Tue, 22 Sep 2020 at 19:47, Lucas Castro > wrote:



On 9/22/20 1:26 PM, James Allsopp wrote:
> Hi,
> I've got a computer that I'm running debian 10 on with KVM. The
> machine is connected to a OpenWRT router which provides DHCP and
DNS
> to the network, via a wifi link used for the host and an ethernet
> connection on eth1 used for a bridge

Is your OpenWRT router running in vm on the same host or somewhere
else
throughout physical network eth1?


The OpenWRT is a completely separate device running at the end of the 
cable connected to eth1. The Wireless is also connected to an AP on 
that router. All of this is on the 192.168.1.* network.


>
> I've set this file up for the bridge in
/etc/network/interfaces.d/br0
> auto eth1
> auto br0
> iface br0 inet dhcp
> bridge_ports eth1
> bridge_fd 0
> bridge_stp off
>
> ifup br0 brought it up nicely and it got an IP address in the range
> I'd expect. So far so good. The only problem is now, I can't get
any
> of the VM's I create to use this network. When creating a VM using
> Virtual Machine Manager, it gives me the option to specify shared
> device name for the network source. One of these is for a network I
> already created in virsh;
>
> 
>   host-bridge
>   
>   
> 


Try something like this ti get your vm settings.

virsh -c qemu:///system dumpxml ${GUEST_NAME} | egrep -A5 -i 
"network|bridge"



i.e.

virsh -c qemu:///system dumpxml Buster | egrep -A5 -i "network|bridge"
    
  
  
  
  
  
  function='0x0'/>

    
    
  
  
  
  
  
  function='0x0'/>

    


>
> However, if I set the network to either 'host-bridge' or br0
directly,
> the route is never set and I can never get  a dhcp setting. I've
> checked ip_forward is set to 1.
>
> I'd just like to set it up this way, as it seems really
inefficient to
> have a dhcp and then use difficult to remember static IP's
everywhere.
>
> Thanks
> James
>
>
-- 
Lucas Castro



--
Lucas Castro

Re: weird behaviour of quotes in bash variable assignments

[Greg Wooledge]

On Tue, Sep 22, 2020 at 04:37:40PM -0400, Gary Dale wrote:
> The smallest complete script then is
> 
> report=”/root/clamscan-report”
> echo $report

There are three errors in this script.

1) There is no shebang line.
2) You've got curly quotes instead of ASCII double-quotes.
3) You used a variable expansion without enclosing it in double quotes,
   in a context where that matters.

If you literally can't see the difference between ”/root/clamscan-report”
and "/root/clamscan-report" (the former is what you have, and the latter
is what it *should* be), then you need to start working with a different
font.

Re: dhcp bridge for virtual machines using KVM

[James Allsopp]

On Tue, 22 Sep 2020 at 17:58, Fabien Roucaute 
wrote:

> Le 22/09/2020 à 18:50, James Allsopp a écrit :
> >
> > I've tried that but I get the same result.
> > Thanks
> > James
> >
>
> You need to answer to the mailing-list email address, not mine.
> If it still doesn't work, we need more information, like the result of
> the following commands (you should modify the public IP that appears in
> if it's the case)
> 'ip a'
> 'iptables-save'
> 'brctl show'
>
>
Here's ip a
 ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc pfifo_fast
state DOWN group default qlen 1000
link/ether 00:1d:7d:0d:2a:9f brd ff:ff:ff:ff:ff:ff
3: eth1:  mtu 1500 qdisc pfifo_fast master
br0 state UP group default qlen 1000
link/ether 00:1d:7d:0d:2a:9d brd ff:ff:ff:ff:ff:ff
4: wlan0:  mtu 1500 qdisc noqueue state UP
group default qlen 1000
link/ether b4:ee:b4:84:37:2a brd ff:ff:ff:ff:ff:ff
inet 192.168.1.174/24 brd 192.168.1.255 scope global dynamic
noprefixroute wlan0
   valid_lft 27656sec preferred_lft 27656sec
inet6 fde6:4511:f54::a55/128 scope global noprefixroute
   valid_lft forever preferred_lft forever
inet6 fde6:4511:f54:0:f195:8361:215d:5f17/64 scope global noprefixroute
   valid_lft forever preferred_lft forever
inet6 fe80::4bf0:ca57:25f0:ed7f/64 scope link noprefixroute
   valid_lft forever preferred_lft forever
5: br0:  mtu 1500 qdisc noqueue state UP
group default qlen 1000
link/ether 00:1d:7d:0d:2a:9d brd ff:ff:ff:ff:ff:ff
inet 192.168.1.206/24 brd 192.168.1.255 scope global dynamic br0
   valid_lft 27655sec preferred_lft 27655sec
inet6 fde6:4511:f54:0:21d:7dff:fe0d:2a9d/64 scope global dynamic
mngtmpaddr
   valid_lft forever preferred_lft forever
inet6 fe80::21d:7dff:fe0d:2a9d/64 scope link
   valid_lft forever preferred_lft forever
6: docker0:  mtu 1500 qdisc noqueue
state DOWN group default
link/ether 02:42:12:5f:1a:5e brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
   valid_lft forever preferred_lft forever
8: vnet0:  mtu 1500 qdisc pfifo_fast
master br0 state UNKNOWN group default qlen 1000
link/ether fe:54:00:8a:6e:57 brd ff:ff:ff:ff:ff:ff
inet6 fe80::fc54:ff:fe8a:6e57/64 scope link
   valid_lft forever preferred_lft forever


Here's iptables -L
 iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source   destination

Chain FORWARD (policy DROP)
target prot opt source   destination
DOCKER-USER  all  --  anywhere anywhere
DOCKER-ISOLATION-STAGE-1  all  --  anywhere anywhere
ACCEPT all  --  anywhere anywhere ctstate
RELATED,ESTABLISHED
DOCKER all  --  anywhere anywhere
ACCEPT all  --  anywhere anywhere
ACCEPT all  --  anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination

Chain DOCKER (1 references)
target prot opt source   destination

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target prot opt source   destination
DOCKER-ISOLATION-STAGE-2  all  --  anywhere anywhere
RETURN all  --  anywhere anywhere

Chain DOCKER-ISOLATION-STAGE-2 (1 references)
target prot opt source   destination
DROP   all  --  anywhere anywhere
RETURN all  --  anywhere anywhere

Chain DOCKER-USER (1 references)
target prot opt source   destination
RETURN all  --  anywhere anywhere

and brctl show

bridge name bridge id   STP enabled interfaces
br0 8000.001d7d0d2a9d   no  eth1
vnet0
docker0 8000.0242125f1a5e   no

Thanks!
James

Re: dhcp bridge for virtual machines using KVM

[James Allsopp]

On Tue, 22 Sep 2020 at 19:47, Lucas Castro  wrote:

>
> On 9/22/20 1:26 PM, James Allsopp wrote:
> > Hi,
> > I've got a computer that I'm running debian 10 on with KVM. The
> > machine is connected to a OpenWRT router which provides DHCP and DNS
> > to the network, via a wifi link used for the host and an ethernet
> > connection on eth1 used for a bridge
>
> Is your OpenWRT router running in vm on the same host or somewhere else
> throughout physical network eth1?
>
>
The OpenWRT is a completely separate device running at the end of the cable
connected to eth1. The Wireless is also connected to an AP on that router.
All of this is on the 192.168.1.* network.



> >
> > I've set this file up for the bridge in /etc/network/interfaces.d/br0
> > auto eth1
> > auto br0
> > iface br0 inet dhcp
> > bridge_ports eth1
> > bridge_fd 0
> > bridge_stp off
> >
> > ifup br0 brought it up nicely and it got an IP address in the range
> > I'd expect. So far so good. The only problem is now, I can't get any
> > of the VM's I create to use this network. When creating a VM using
> > Virtual Machine Manager, it gives me the option to specify shared
> > device name for the network source. One of these is for a network I
> > already created in virsh;
> >
> > 
> >   host-bridge
> >   
> >   
> > 
> >
> > However, if I set the network to either 'host-bridge' or br0 directly,
> > the route is never set and I can never get  a dhcp setting. I've
> > checked ip_forward is set to 1.
> >
> > I'd just like to set it up this way, as it seems really inefficient to
> > have a dhcp and then use difficult to remember static IP's everywhere.
> >
> > Thanks
> > James
> >
> >
> --
> Lucas Castro
>
>

Re: linux isn't robust enough to handle bad sector??

[David Christensen]

On 2020-09-22 03:06, Long Wind wrote:
  
 On Tuesday, September 22, 2020, 2:45:30 AM EDT, David Christensen  wrote:
  
Seagate SeaTools Bootable is a USB flash drive live Linux distribution

with an app for testing Seagate products.  Microsoft Windows is not
required:

https://www.seagate.com/support/downloads/seatools/

That is a vintage computer.  But, I would expect it to work with the
Seagate ST3320311CS; if both are in proper working order.

Test the Seagate ST3320311CS using the ThinkCentre and Seagate SeaTools
Bootable.
it has only exe file, no iso file, you need Windows


Sorry about that.  I burned Seagate SeaTools Bootable to a USB flash 
drive a few years ago and forgot the details.



I have sent a support request to Seagate asking them to post an *.img 
file of SeaTools Bootable that can be copied to a USB flash drive using 
Linux/ BSD/ Unix and dd(1).



That said, the harsh reality of running Linux, BSD, etc., on Intel x86/ 
x86-64 hardware is that you must maintain at least one working Windows 
installation.



I bought a Windows 7 Pro COA from a recycled laptop on eBay for $25. 
These are still available.



I am disinclined to set up a Windows 10 installation as it involves 
joining the Microsoft collective.  I seem to recall reading a post that 
there is a way to bypass assimilation -- I will need to research it when 
Windows 7 no longer meets my needs.



Perhaps you should use the Seagate ST3320311CS for Windows.



https://www.seagate.com/files/old-support-files/seatools/USBbootSetup-SeaToolsBootable.zip
and i have little reason to do more test. it has passed short and long tests by smart and badblocks tests. i've removed it from hp to thinkcentre, 


So, the drive passed all smartctl(8) and badblocks(8) tests in the HP, 
the ThinkCentre, or both?



Have you purchased and installed new SATA 6 Gbps cables?



and easily created FS. its problem with hp won't be solved by tool from 
seagate. i'll just use it in thinkcentre.


Be sure to use a file system that can detect bit rot -- either btrfs or 
ZFS -- and back up frequently.



David

Re: ssh session times out annoyingly fast, why?

[Darac Marjal]

On 22/09/2020 00:38, Britton Kerin wrote:
> I'm using ssh from a debian box to a rasberry pi (sorta debian also :).
>
> For some reason ssh sessions seem to time out pretty quickly.  I've
> tried setting ClientAliveInterval and ClientAliveCountMax and also
> ServerAliveInterval  and ServerAliveCountMax, but it doesn't seem to
> make any difference.  Is there some other setting somewhere that
> affects this?

Have a look at the environmental variable TMOUT. From the bash manpage:

  TMOUT  If set to a value greater than zero, TMOUT is treated as
the default timeout for the read builtin.  The select command terminates
if input does not arrive after TMOUT seconds when input is coming from a
terminal.  In  an interactive  shell,  the  value  is interpreted as the
number of seconds to wait for a line of input after issuing the primary
prompt.  Bash terminates after waiting for that number of seconds if a
complete line of input does not arrive.


>
> Thanks,
> Britton
>



signature.asc
Description: OpenPGP digital signature

Re: dhcp bridge for virtual machines using KVM

[Lucas Castro]

On 9/22/20 1:26 PM, James Allsopp wrote:

Hi,
I've got a computer that I'm running debian 10 on with KVM. The 
machine is connected to a OpenWRT router which provides DHCP and DNS 
to the network, via a wifi link used for the host and an ethernet 
connection on eth1 used for a bridge


Is your OpenWRT router running in vm on the same host or somewhere else 
throughout physical network eth1?





I've set this file up for the bridge in /etc/network/interfaces.d/br0
auto eth1
auto br0
iface br0 inet dhcp
bridge_ports eth1
bridge_fd 0
bridge_stp off

ifup br0 brought it up nicely and it got an IP address in the range 
I'd expect. So far so good. The only problem is now, I can't get any 
of the VM's I create to use this network. When creating a VM using 
Virtual Machine Manager, it gives me the option to specify shared 
device name for the network source. One of these is for a network I 
already created in virsh;



  host-bridge
  
  


However, if I set the network to either 'host-bridge' or br0 directly, 
the route is never set and I can never get  a dhcp setting. I've 
checked ip_forward is set to 1.


I'd just like to set it up this way, as it seems really inefficient to 
have a dhcp and then use difficult to remember static IP's everywhere.


Thanks
James



--
Lucas Castro

Re: dhcp bridge for virtual machines using KVM

[Fabien Roucaute]

Le 22/09/2020 à 18:50, James Allsopp a écrit :
> 
> I've tried that but I get the same result.
> Thanks
> James
> 

You need to answer to the mailing-list email address, not mine.
If it still doesn't work, we need more information, like the result of
the following commands (you should modify the public IP that appears in
if it's the case)
'ip a'
'iptables-save'
'brctl show'

Re: dhcp bridge for virtual machines using KVM

[Fabien Roucaute]

Le 22/09/2020 à 18:26, James Allsopp a écrit :
> Hi,
> I've got a computer that I'm running debian 10 on with KVM. The machine
> is connected to a OpenWRT router which provides DHCP and DNS to the
> network, via a wifi link used for the host and an ethernet connection on
> eth1 used for a bridge
> 
> I've set this file up for the bridge in /etc/network/interfaces.d/br0
> auto eth1
> auto br0
> iface br0 inet dhcp
> bridge_ports eth1
> bridge_fd 0
> bridge_stp off
> 
> ifup br0 brought it up nicely and it got an IP address in the range I'd
> expect. So far so good. The only problem is now, I can't get any of the
> VM's I create to use this network. When creating a VM using Virtual
> Machine Manager, it gives me the option to specify shared device name
> for the network source. One of these is for a network I already created
> in virsh;
> 
> 
>   host-bridge
>   
>   
> 
> 
> However, if I set the network to either 'host-bridge' or br0 directly,
> the route is never set and I can never get  a dhcp setting. I've checked
> ip_forward is set to 1.
> 
> I'd just like to set it up this way, as it seems really inefficient to
> have a dhcp and then use difficult to remember static IP's everywhere.
> 
> Thanks
> James
> 
> 
You don't need to create a virtual network to 'plug' your vm on the
brigde using the host NIC. Just select the br0 bridge as the source on
the VM's NIC hardware settting.

Re: Encodage de fichiers provenant de système Microsoft

[steve]

Salut Marc,

Merci pour ce petit cours accéléré :)

Beaucoup plus clair maintenant.

Comme je l'ai dit dans un autre message, je vais voir en amont si on
peut faire quelque chose.

Encore merci !

S

dhcp bridge for virtual machines using KVM

[James Allsopp]

Hi,
I've got a computer that I'm running debian 10 on with KVM. The machine is
connected to a OpenWRT router which provides DHCP and DNS to the network,
via a wifi link used for the host and an ethernet connection on eth1 used
for a bridge

I've set this file up for the bridge in /etc/network/interfaces.d/br0
auto eth1
auto br0
iface br0 inet dhcp
bridge_ports eth1
bridge_fd 0
bridge_stp off

ifup br0 brought it up nicely and it got an IP address in the range I'd
expect. So far so good. The only problem is now, I can't get any of the
VM's I create to use this network. When creating a VM using Virtual Machine
Manager, it gives me the option to specify shared device name for the
network source. One of these is for a network I already created in virsh;


  host-bridge
  
  


However, if I set the network to either 'host-bridge' or br0 directly, the
route is never set and I can never get  a dhcp setting. I've checked
ip_forward is set to 1.

I'd just like to set it up this way, as it seems really inefficient to have
a dhcp and then use difficult to remember static IP's everywhere.

Thanks
James

traps: courieresmtp

[Philipp Ewald]

Hello,

maybe i found a bug in courier.

courier crash's when a E-Mail address contains "–" (EN DASH)

Kernel log:
traps: courieresmtp[36082] general protection

mail.log:
courieresmtp: Crashed child process 41684, while delivering to DO<96>MAIN.TLD

When i try to send a mail to DO–MAIN.TLD via thunderbird (smtp server is the same) or 
something else Server report: No such domain (replace DO–MAIN.TLD with a real domain 
containing normal "-")

Mail was send via .mailfilter (auto reply)

is this a bug from courier? debian? maildrop?


kind regards
Philipp

--
Philipp Ewald
Administrator

DigiOnline GmbH, Probsteigasse 15 - 19, 50670 Köln
E-Mail: philipp.ew...@digionline.de

AG Köln HRB 27711, St.-Nr. 5215 5811 0640
Geschäftsführer: Werner Grafenhain

Informationen zum Datenschutz: www.digionline.de/ds

Re: weird behaviour of quotes in dash variable assignments

[David Wright]

On Mon 21 Sep 2020 at 20:50:29 (-0400), Gary Dale wrote:
> On 2020-09-21 10:30, David Wright wrote:
> > On Mon 21 Sep 2020 at 08:18:52 (-0400), Greg Wooledge wrote:
> > > On Mon, Sep 21, 2020 at 07:55:45AM -0400, Cindy Sue Causey wrote:
> > > > '…' and "…" are known as neutral, vertical, straight, typewriter,
> > > > dumb, or ASCII quotation marks.
> > > > 
> > > > ‘…’ and “…” are known as typographic, curly, curved, book, or smart
> > > > quotation marks.
> > > Yes.  This is one of the possible causes for the behavior the OP was
> > > reporting.  But if this is true, then it reveals that they were lying
> > > when they claimed that the scripts were the same on both servers.
> > > 
> > > […]
> > > 
> > > To beat a dead horse some more, if *this* was the OP's problem, then they
> > > told multiple lies about it.  They did not paste the actual failing line
> > > from the failing script (probably retyped it instead), and they did not
> > > ACTUALLY COMPARE the two scripts to see whether they were different,
> > > instead simply ASSUMING that the two scripts were identical, even though
> > > they very clearly weren't.
> > > 
> > > An actual troubleshooting would have done something like using md5sum
> > > on the script on each machine, and pasting the md5sum commands (including
> > > the full script pathname) and their output to the mailing list.  Openness.
> > > 
> > > Or, hell, even "ls -l /full/pathname" would probably have revealed that
> > > the scripts were not the same SIZE.  That would also have shown 
> > > immediately
> > > that the scripts were not "the same".
> > I think we should apply Hanlon's razor rather than saying the OP lied.
> > After all, "compare" means diff or cmp to us, whereas many might just
> > use their eyeballs. And we all know that authors are the worst people
> > to check their own work. Proof-reading is a special skill.
> > 
> > Even their fix is poorly described. Did they just type the quotes back
> > in with an editor, in which case there's no guarantee that the scripts
> > are identical between machines, or did they transfer a working script
> > to the failing machine? The best line is save until last: "I certainly
> > didn't update anything on either server...". Well, yes, that's
> > *precisely* what you did: you updated the script.
  ↑↑
> > 
> You are taking my quote out of context. I didn't change anything on
> the server to make the script start working. I updated the script to
   
> see if it would work after trying Greg's test. There were no program
> or setting updates on the server, and certainly nothing that updated
> dash. This is Debian/Stable we're talking about, after all.

Sorry, I thought you wrote that on Sunday afternoon, "I fixed it by
removing the quotes on the one server but now the scripts are
different between the two servers, which isn't what I want."
Then on Sunday evening, you wrote "When I retried my script with the
quotes, it started working."

The general opinion is that the script was faulty, probably in the
quotes used. The narrative says that you removed the quotes, and
later put them back. It seems fair to suggest that the quotes you
put back were not the same ones that you removed. They were replaced
in the same location, but you didn't put the old (removed) quotes
into a little two-character file, so that you could put precisely
the same ones back into the script, did you?

> Since it is a file server, there probably were changes to the files on
> its shares, but I'd hardly count that as an "update". Similarly, it
> was running cron jobs for backups and virus scans (unsuccessfully) but
> again I wouldn't call those "updates".

Nor I. No, I'm only talking about your script. Does it bear any
relation to the one posted in your blog? The first line (after
the shebang) of the one in the blog is the same line that's under
discussion here, and has curly quotes. I can't parse the second
line's curly quotes, and the fourth line uses an n-dash for a
hyphen *though the other hyphens are ok). The fifth line uses
curly single-quotes. More curly quotes follow.

I don't see any cause for our wasting time pondering on dash
without your posting an MWE that unambiguously demonstrates a
problem.

Cheers,
David.

Re: linux isn't robust enough to handle bad sector??

[David Wright]

On Tue 22 Sep 2020 at 10:06:46 (+), Long Wind wrote:
> On Tuesday, September 22, 2020, 2:45:30 AM EDT, David Christensen 
>  wrote:  
>  
> Seagate SeaTools Bootable is a USB flash drive live Linux distribution 
> with an app for testing Seagate products.  Microsoft Windows is not 
> required:
> 
> https://www.seagate.com/support/downloads/seatools/
> 
> That is a vintage computer.  But, I would expect it to work with the 
> Seagate ST3320311CS; if both are in proper working order.
> 
> Test the Seagate ST3320311CS using the ThinkCentre and Seagate SeaTools 
> Bootable.
> it has only exe file, no iso file, you need Windows
> https://www.seagate.com/files/old-support-files/seatools/USBbootSetup-SeaToolsBootable.zip
> and i have little reason to do more test. it has passed short and long tests 
> by smart and badblocks tests. i've removed it from hp to thinkcentre, and 
> easily created FS. its problem with hp won't be solved by tool from seagate. 
> i'll just use it in thinkcentre.
> Thank Reco for educational post on bad sector!i've just read it and found it 
> instructive. 

You picked the wrong file to download. Go back to the
https://www.seagate.com/support/downloads/seatools/
page and read the text in the corner of the browser
window as the mouse hovers over the big blobs.
The second blob down goes to
https://www.seagate.com/support/downloads/seatools/seatools-legacy-support-master/
Here you will find graphical and text versions that
are bootable ISOs which run under FreeDOS:
https://www.seagate.com/files/www-content/support-content/downloads/seatools/_shared/downloads/SeaToolsDOS223ALL.ISO
and
https://www.seagate.com/files/www-content/support-content/downloads/seatools/_shared/downloads/SeaToolsDOS112.ISO
with instructions:
https://www.seagate.com/files/staticfiles/support/downloads/seatools/seatools-dos-guide.pdf
Download those.

Cheers,
David.

Re: Bug report: prog run via keyboard shortcut gets a different SSH agent?

[Greg Wooledge]

On Tue, Sep 22, 2020 at 09:10:15AM +1000, Michael Slade wrote:
> I don't know what package to assign this to so I guess I can't use the usual
> bug reporting mechanism.
> 
> I have a debian bullseye mate desktop with a custom keyboard shortcut set up
> to run xterm.  I noticed that an ssh agent is automatically set up for it,
> but a different agent is set up for programs that are run other ways,
> including via the default C-A-t shortcut for the default terminal.

It sounds like MATE is starting to become more GNOME-3-like.  What a shame.

You'll want to talk to MATE or GNOME experts, but it sounds to me like
the terminal that gets spawned by C-A-t is a child of dbus, rather than
a child of the X or Wayland session.  And just like in GNOME 3, when that
happens, the terminal (and thus, the shell within it) does NOT inherit
your normal environment.

You could verify this yourself, perhaps, by printing a tree-view of your
processes, and seeing who the parent of the offending terminal is.  I bet
it'll be dbus.

With your xterm, on the other hand, I suspect that your keybaord shortcut
is launching it as a child of your window manager, or some other part of
your MATE session.  Therefore, it inherits the same environment that your
other desktop session programs have.

LXDE and Applets

[Hans]

Hi folks, 

at the moment I am exploring an issue with LXDE and applets. The issue is the 
following:

When I first start the computer and start LXDE (system is debian/testing), 
then some applets fail to initialise. This I noticed with the powermanagement 
applet and nm-applet.

The first one is not starting at all, the seond one is starting, but is 
telling, that the networkservice (NetworkManager) is not running (although it 
is!)

When I then stop LXDE and start it again, then everything is working fine. I 
think of a timing problem, but have no clue, where I should look at.

The logs didn't show anything related to this and I did not succeed, to appear 
this issue by manually actions (like starting Networkmanager later or 
similar).

There is a bugreport by me to the package "nm-applet-gnome", where is describe 
this behaviour, but at the momengt I am not sure, if nm-applet is buggy. 

Looks somehow more than a bug in LXDE.

BTW: In plasma5 it is all working well!

It would be nice, if someone could confirm this behaviour or knows more than 
I, so that we could file a bugreport to the correct address.

At the moment I am completely stuck.

Thanks for reading this and any help.

Best regards

Hans 

Re: Toujours des plantage Xorg

[Daniel Caillibaud]

Le 18/09/20 à 19:15, BERTRAND Joël  a écrit :
>   Le dual screen ne serait-il pas pour quelque chose dans le problème ?

Pas chez moi, ça vient de planter sans dual screen…

-- 
Daniel

Il est souvent trop tôt pour savoir s'il n'est pas
trop tard.
Pierre Dac

arc_meta_used > arc_meta_limit, need tuning hints

[Victor Sudakov]

Dear Colleagues,

On a system with many small files, I often observe arc_meta_used over 
arc_meta_limit:

# grep arc_m /proc/spl/kstat/zfs/arcstats 
arc_meta_used   45580987440
arc_meta_limit  45532735283
arc_meta_max46179223472
arc_meta_min416777216
# 

I think the situation is abnormal and degrades performance. Running
"echo 3 > /proc/sys/vm/drop_caches" clears the situation ... for a while. 

I've tried increasing zfs_arc_dnode_limit_percent and
arc_meta_limit_percent to no avail. What else can I tune?

Debian 10, zfs-0.8.4-2~bpo10+1

-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/


signature.asc
Description: PGP signature

Re: ssh session times out annoyingly fast, why?

[Toni Mas Soler]

First, you should be sure it is not a network issue.
You could open a terminal and run, for example, top program. This
avoid any timeout configured. If this does not work, you should follow
for a network issue, otherwise we can see sshd's config file.

Toni Mas

Missatge de Britton Kerin  del dia dt., 22 de
set. 2020 a les 1:38:
>
> I'm using ssh from a debian box to a rasberry pi (sorta debian also :).
>
> For some reason ssh sessions seem to time out pretty quickly.  I've
> tried setting ClientAliveInterval and ClientAliveCountMax and also
> ServerAliveInterval  and ServerAliveCountMax, but it doesn't seem to
> make any difference.  Is there some other setting somewhere that
> affects this?
>
> Thanks,
> Britton
>

Re: Securing local host of reverse SSH tunnel?

[Alex Mestiashvili]

On 9/17/20 1:27 AM, Nate Bargmann wrote:

* On 2020 16 Sep 12:08 -0500, Alex Mestiashvili wrote:


btw, there is package authprogs, doing exactly that and not only.


It seems to only be in Bullseye right now.  It's not in Buster nor
Buster backports.  As the target computer is a Freedombox, it is running
Buster so I will have to see if I can build it locally.

- Nate



it should be as easy as pip --user install authprgos, but it is also 
available in buster-backports from today.


Best,
Alex

Re: Encodage de fichiers provenant de système Microsoft

[Marc Chantreux]

salut,

> > ben du coup c'est pas ton fs qui supporte pas les caractères utf8 dans
> > le fichier?
> Si si, tout mon système est en UTF-8.

c'est ce que disait Nicolas: c'est pas le FS qui est pas utf-8 mais le
nom du fichier qui est probablement en latin9.


> > C  o  m  i  t  ? _  d  e  p  i  l  o  t  a  g  e
> > c'est ce que ls affiche.  2b ae est donc la représentation que ls fait
> > de ton char foireux
> Je ne sais pas comment tu es arrivé à cette conclusion mais je te crois
> sur parole ;-)
> > et j'espérais pouvoir en faire quelque chose pour
> > écrire une macro mutt.

avec xxd c'est plus simple a expliquer:

* un charmap une chaine de caractère, c'est une suite d'octets (souvent
  1 seul octet) associée à un symbole.  quand tu as le problème que tu
* as eu, c'est tout simplement que 2 outils n'utilisent pas le meme charmap
* du coup, regarder la valeur de l'octet et trouver le charmap dans
  lequel ca correspond à la valeur attendue permet souvent de trouver
  une solution

echo -n steve|xxd -b -c1

: 01110011  s
0001: 01110100  t
0002: 01100101  e
0003: 01110110  v
0004: 01100101  e

sauf que tous ces bits, c'est compliqué et long a lire ou a memoriser
alors on utilise une autre notation (hexadecimale) qui a une propriété
intéressante: on peut regrouper les bits par 4 pour 1 seul symbole
hexa.

voilà une table de conversion decimal/hexa/ascii

00 00 00
01 01 01
02 02 10
03 03 11
04 04 000100
05 05 000101
06 06 000110
07 07 000111
08 08 001000
09 09 001001
10 0a 001010
11 0b 001011
12 0c 001100
13 0d 001101
14 0e 001110
15 0f 00
16 10 01
17 11 010001
18 12 010010
19 13 010011
20 14 010100

du coup le s par exemple:

0111 => 7
0011 => 3

echo -n steve|xxd -b -c1

: 73  s
0001: 74  t
0002: 65  e
0003: 76  v
0004: 65  e

> > va renommer 北亰.pdf et تج.xls en Bei Jing .pdf et tj.xls

> Un mv le permet aussi presque toujours.

oui mais avec mv t'es obligé de deviner le nom des symboles.

bon de toute façon ca colle plus trop puisque comme le signalait
Nicolas: le problème est l'exact inverse: c'est ton fichier qui est
nommé avec des caractères non-utf.

a+
marc

Re: ifup gets different IPv6 address than Network Manager

[Andrei POPESCU]

On Lu, 21 sep 20, 17:59:33, Nate Bargmann wrote:
> 
> In the OpenWRT DHCP configuration I have included an IPv6 Suffix
> parameter for all hosts.  However, until I enabled the hosts to receive
> a DHCP address via ifup, I had never seen an IPv6 address that included
> that suffix.  The ifup enabled hosts all receive an IPv6 address that
> ends with this configured suffix, which is exactly what I would like the
> hosts that use Network Manager to receive as well.  The suffixes I have
> assigned have a relationship to the IPv4 addresses I have assigned each
> host so this is a handy way for me to visually associate an IPv6 address
> to a host.
> 
> Has anyone managed to get Network Manager to work in a like manner?

I'm using a slightly different configuration, with the suffix configured 
in the host[1].

In the IPv6 Settings tab of the connection try setting the "Method" to 
"Automatic, DHCP only". The default appears to be "Automatic" which 
could also imply SLAAC.

[1] this must be done in the configuration file, at least on buster it's 
not exposed in the GUI connection editor.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: linux isn't robust enough to handle bad sector??

[David Christensen]

On 2020-09-21 21:41, Long Wind wrote:


seagate's new tool is for Windows, i've not used Windows for long timei've read 
their guide for old tool, its function look like smart tooli'm afraid  it won't 
be helpful to my diagnosis effort


Seagate SeaTools Bootable is a USB flash drive live Linux distribution 
with an app for testing Seagate products.  Microsoft Windows is not 
required:


https://www.seagate.com/support/downloads/seatools/



my hp dx5150 pc probably supports sata1 onlyand it work well with Western 
Digital sata3 320G diskbut seem to have trouble with Seagate problem diskit 
probably caused 2 linux installation failures


That is a vintage computer.  But, I would expect it to work with the 
Seagate ST3320311CS; if both are in proper working order.




problem disk seem to have less trouble  with my more modern ThinkCentrewhich 
supports sata2


Test the Seagate ST3320311CS using the ThinkCentre and Seagate SeaTools 
Bootable.



David