On Tue, Oct 17, 2023 at 05:43:55PM +0200, Gertjan Klein wrote:
> This works, but the mail
> from address looks like this: "gklein ". This irks me.
> My account has my full name configured; why isn't it used? I am testing
> this as follows:
>
> $ echo "this
elsewhere. This works, but the mail
from address looks like this: "gklein ". This irks me.
My account has my full name configured;
Where exactly is the full name configured?
I meant the user account on that machine:
gklein@parvos:~$ cat /etc/passwd | grep gklein
gklein:x:1000:1000:Ger
from address looks like this: "gklein ". This irks me.
> My account has my full name configured;
Where exactly is the full name configured?
> why isn't it used?
That is reason for the above question.
> I am testing this as follows:
>
> $ echo "this is a test&
I am configuring a new VPS, and decided to try nullmailer to send mail.
I don't want to receive mail on the VPS, I just want the mail the system
generates to end up in my mailbox elsewhere. This works, but the mail
from address looks like this: "gklein ". This irks me.
My account has my
Hi Paul,
On Thu, Jun 29, 2023 at 06:27:02PM +0200, Paul Leiber wrote:
> Just to state the obvious, what's bothering me is that my setup was working
> with kernel 5.10.0-21 and that it stopped working with kernel 5.10.178-3. So
> it seems that somewhere inbetween, changes have been introduced that
iotlb buffer is full" entries while
failing to load the driver during the boot process:
I don't think you'll get better response here than you will from the
Xen project. You might want to try asking on xen-devel as opposed to
xen-users, though they will expect you to use their upstream source
rently running Debian 11 bullseye.
> >We want to perform a full upgrade to Debian 12 aka "bookworm." I know a
> set of "instructions" for the install exists but Not for our needs.
> >We cannot locate the EXACT, STRAIGHTFORWARD Instructions on HOW to do the
> proce
Dear Sir or madam,
So, We see you write like a bot.
So, We think #1 is YES
So, We say the last question is FOLLOW the release notes on upgrading.
We thank you for the Turing test
>Sirs,
>We are currently running Debian 11 bullseye.
>We want to perform a full upgrade to Debian 12 aka
n-reply-to=XiU7aqJHm8EPZSELf5B_eodPqg8yQVS1US81CJSRg_o7YU07_A8R6GHA3ZexhKAuYvB1Yjdu7AzWHUJz5bKAzu6a44i308CGtQ6zDXM_ns8=@protonmail.com
>I know a set of "instructions" for the install exists but Not for our needs.
That is a ridiculous statement.
Hi Paul,
On Wed, Jun 28, 2023 at 09:40:52PM +0200, Paul Leiber wrote:
> In the meantime, I have upgraded Dom0 to Debian Bookworm with
> linux-image-amd64 6.1.27-1 and Xen 4.17. The issue persists, seemingly
> unchanged.
>
> In DomU dmesg, there are several "swiotlb buffer is
On Wed, 28 Jun 2023 17:59:20 -0400
Greg Wooledge wrote:
> In addition, you change "non-free" to "non-free non-free-firmware".
> This is the new thing for bookworm.
This should do it (mind the wrapping!):
# If this is bookworm, and it hasn't already been done (e.g. by
# preseeding), add
ftware.
You're overthinking it. The upgrade steps for bookworm are very similar
to previous upgrades. The main difference is that a *second* change is
needed to sources.list.
> > So, The Last Question Is: How do I perform the Full Upgrade to "bookworm"
> > that INCLUDES the no
On Wed, Jun 28, 2023 at 08:16:20PM +, Patriot wrote:
> Sirs,
> We are currently running Debian 11 bullseye.
> We want to perform a full upgrade to Debian 12 aka "bookworm." I know a set
> of "instructions" for the install exists but Not for our nee
Sirs,
We are currently running Debian 11 bullseye.
We want to perform a full upgrade to Debian 12 aka "bookworm." I know a set of
"instructions" for the install exists but Not for our needs.
We cannot locate the EXACT, STRAIGHTFORWARD Instructions on HOW to do the
pro
by
increasing Dom0 memory).
In the meantime, I have upgraded Dom0 to Debian Bookworm with
linux-image-amd64 6.1.27-1 and Xen 4.17. The issue persists, seemingly
unchanged.
In DomU dmesg, there are several "swiotlb buffer is full" entries while
failing to load the driver during the bo
ernet. De buenas a
> primeras los backup full de un cliente local falla y lanza mensajes de error
> del tipo:
>
> JobId 9387: Error: bsock.c:429 Write error sending 11068 bytes to Storage
> daemon:X:9103: ERR=Connection reset by peer
> JobId 9387: Fatal error: backup.c:12
Tengo un sistema Debian 10 que tiene el servicio Bacula cumpliendo su función
desde hace años, los clientes pueden ser máquinas físicas o virtuales de tipo
Centos o Ubuntu o Debian, uno de los clientes está en internet. De buenas a
primeras los backup full de un cliente local falla y lanza
On Mon, Mar 06, 2023 at 10:41:22AM +, Jonathan Dowland wrote:
Quite. I habitually alias ls to 'ls -lhrt', (and cdls() { cd "$@" && ls
-lhrt; }; alias cd=cdls) so I'm very used to only looking at the bottom
of a long list of size-sorted-ascending.
Err, of course, that's
On Sat, Mar 04, 2023 at 11:10:48AM -0600, David Wright wrote:
But then when there's a drove, the biggest go AWOL
off the top of screen.
Quite. I habitually alias ls to 'ls -lhrt', (and cdls() { cd "$@" && ls
-lhrt; }; alias cd=cdls) so I'm very used to only looking at the bottom
of a long
On Fri 03 Mar 2023 at 15:42:37 (-), Curt wrote:
> On 2023-03-02, Jonathan Dowland wrote:
> > On Thu, Mar 02, 2023 at 07:25:58AM -0500, Greg Wooledge wrote:
> >>I don't understand why you used sort -r, but then reversed it again with
> >>tac at the end. You could drop both of the reversals,
On 3/2/23 15:16, songbird wrote:
i could find a lot of space by deduping backups and pictures
but that is on my TODO list for the year 2026 at the rate i'm
going. it may end up being much more time efficient to just
go out and buy another 2TB SSD and swap that for my smaller
one and call it
On Fri, 3 Mar 2023 Curt wrote:
On 2023-03-02, Jonathan Dowland wrote:
On Thu, Mar 02, 2023 at 07:25:58AM -0500, Greg Wooledge wrote:
I don't understand why you used sort -r, but then reversed it again with
tac at the end. You could drop both of the reversals, and just change
head to tail.
On 2023-03-02, Jonathan Dowland wrote:
> On Thu, Mar 02, 2023 at 07:25:58AM -0500, Greg Wooledge wrote:
>>I don't understand why you used sort -r, but then reversed it again with
>>tac at the end. You could drop both of the reversals, and just change
>>head to tail.
>
> The short answer is
On 2/03/23 06:00, Andy Smith wrote:
Hi,
On Wed, Mar 01, 2023 at 02:35:17PM +0100, lina wrote:
My / is almost full.
# df -h
Filesystem Size Used Avail Use% Mounted on
udev126G 0 126G 0% /dev
tmpfs26G 2.3M 26G 1% /run
/dev/nvme0n1p2 23G 21G 966M
On Thu 02 Mar 2023 at 18:09:06 (-0500), songbird wrote:
> Joe wrote:
> ...
> > On unstable, I have a /var/cache/apt/archives directory, from which apt
> > autoclean, which I do occasionally, recently removed about 5G of
> > packages (obviously too occasionally). There's still quite a bit there
> >
Andy Smith wrote:
> Hello,
>
> On Wed, Mar 01, 2023 at 07:53:19PM +0100, Nicolas George wrote:
>> Andy Smith (12023-03-01):
>> > > /dev/nvme0n1p2 23G 21G 966M 96% /
>> > > /dev/nvme0n1p6 267M 83M 166M 34% /boot
>> > > /dev/nvme0n1p1 511M 5.8M 506M 2% /boot/efi
>> > > /dev/nvme0n1p3
Joe wrote:
...
> On unstable, I have a /var/cache/apt/archives directory, from which apt
> autoclean, which I do occasionally, recently removed about 5G of
> packages (obviously too occasionally). There's still quite a bit there
> as it was only autoclean and I prefer to keep downloads around for
On 3/2/23 15:19, Felix Miata wrote:
David Christensen composed on 2023-03-02 14:41 (UTC-0800):
How do I make the settings live (other than rebooting, which might hang
if there is a syntax error)?
I think this is one of those things that systemctl daemon-reload does.
[quote]
So, it's a
David Christensen composed on 2023-03-02 14:41 (UTC-0800):
> How do I make the settings live (other than rebooting, which might hang
> if there is a syntax error)?
I think this is one of those things that systemctl daemon-reload does.
[quote]
So, it's a "soft" reload, essentially; taking
On 3/2/23 14:41, David Christensen wrote:
On 3/2/23 00:53, lina wrote:
> :/usr/lib$ du -sh * | sort -nr | grep -v K | head
> 981M R
> 591M rstudio
> 591M jvm
> 554M mega
> 538M llvm-11
> 343M modules
> 313M libreoffice
So, your computer has 3911M of apps in /usr/share.
Corrections:
On 3/1/23 05:35, lina wrote:
> My / is almost full.
>
> # df -h
> Filesystem Size Used Avail Use% Mounted on
> udev126G 0 126G 0% /dev
> tmpfs26G 2.3M 26G 1% /run
> /dev/nvme0n1p2 23G 21G 966M 96% /
On 3/1/23 15:03, Felix M
On Thu, Mar 02, 2023 at 07:25:58AM -0500, Greg Wooledge wrote:
I don't understand why you used sort -r, but then reversed it again with
tac at the end. You could drop both of the reversals, and just change
head to tail.
The short answer is because I wrote all but the last "tac" several years
On Thu, Mar 02, 2023 at 09:45:38AM +, Jonathan Dowland wrote:
> --✂--✂--✂--✂--✂--✂--✂--✂--✂--✂ --✂--✂--✂--✂--✂--✂--✂--✂--✂--✂--
>
> STATUS_FILE=/var/lib/dpkg/status
> dpigs()
> {
> TL=${1-10}
> awk -v RS='' '/Status:.*installed\n/' "$STATUS_FILE" \
> | grep -E
-goodies (and
associated transitive dependencies), which can be a problem when the
root filesystem is full or nearly so.
A while ago I (privately) re-wrote dpigs in standard tools for this
reason (mostly for operating inside small containers). Once I got to
feature parity I was going to submit
On Wed, Mar 01, 2023 at 02:27:58PM -0700, Charles Curley wrote:
You can find the large directory culprits quickly enough with
cd /
du -h | sort -h
OP demonstrated that they know how to use ncdu, which is a far superior
way of achieving the same result.
Personally I like duc for this job (and
On Thu, Mar 02, 2023 at 09:53:29AM +0100, lina wrote:
> :/usr/lib$ du -sh * | sort -nr | grep -v K | head
> 981M R
> 591M rstudio
> 591M jvm
> 554M mega
> 538M llvm-11
> 343M modules
> 313M libreoffice
Insightful, thanks :)
Cheers
--
t
signature.asc
Description: PGP signature
2:05PM -0500, Greg Wooledge wrote:
>> > On Wed, Mar 01, 2023 at 05:53:18PM -0500, Jeffrey Walton wrote:
>> > > On Wed, Mar 1, 2023 at 8:35 AM lina wrote:
>> > > >
>> > > > My / is almost full.
>>
>> [...]
>>
>> > > &g
:40 AM wrote:
> On Wed, Mar 01, 2023 at 06:12:05PM -0500, Greg Wooledge wrote:
> > On Wed, Mar 01, 2023 at 05:53:18PM -0500, Jeffrey Walton wrote:
> > > On Wed, Mar 1, 2023 at 8:35 AM lina wrote:
> > > >
> > > > My / is almost full.
>
> [...
On Wed, Mar 01, 2023 at 06:12:05PM -0500, Greg Wooledge wrote:
> On Wed, Mar 01, 2023 at 05:53:18PM -0500, Jeffrey Walton wrote:
> > On Wed, Mar 1, 2023 at 8:35 AM lina wrote:
> > >
> > > My / is almost full.
[...]
> > > /dev/nvme0n1p2 23G 21G 966M 96%
On Wed 01 Mar 2023 at 19:53:09 (+), Andy Smith wrote:
> On Wed, Mar 01, 2023 at 07:53:19PM +0100, Nicolas George wrote:
> I was talking about them going to the effort of separating /home and
> /var and ending up with completely inappropriate sizings. They would
> have been much better off just
On Wed, Mar 01, 2023 at 05:53:18PM -0500, Jeffrey Walton wrote:
> On Wed, Mar 1, 2023 at 8:35 AM lina wrote:
> >
> > My / is almost full.
> >
> > # df -h
> > Filesystem Size Used Avail Use% Mounted on
> > udev126G 0 126G 0% /dev
&
Jeffrey Walton composed on 2023-03-01 17:53 (UTC-0500):
> You can probably reclaim a couple of GB by trimming systemd logs. It
> should get you some room to work. Something like:
>journalctl --vacuum-time=14d
I limit journal size this way:
# cat /etc/systemd/journald.conf.d/local.conf
On Wed, Mar 1, 2023 at 8:35 AM lina wrote:
>
> My / is almost full.
>
> # df -h
> Filesystem Size Used Avail Use% Mounted on
> udev126G 0 126G 0% /dev
> tmpfs26G 2.3M 26G 1% /run
> /dev/nvme0n1p2 23G 21G 966M 96% /
> tmpfs
On Wed, 1 Mar 2023 14:35:17 +0100
lina wrote:
> My / is almost full.
>
> # df -h
> Filesystem Size Used Avail Use% Mounted on
> udev126G 0 126G 0% /dev
> tmpfs26G 2.3M 26G 1% /run
> /dev/nvme0n1p2 23G 21G 966M 96% /
Y
On 3/1/23 05:35, lina wrote:
Hi,
My / is almost full.
# df -h
Filesystem Size Used Avail Use% Mounted on
udev126G 0 126G 0% /dev
tmpfs26G 2.3M 26G 1% /run
/dev/nvme0n1p2 23G 21G 966M 96% /
tmpfs 126G 15M 126G 1% /dev/shm
tmpfs
On Wed 01 Mar 2023 at 19:37:10 +0100, to...@tuxteam.de wrote:
> On Wed, Mar 01, 2023 at 06:12:09PM +, Brian wrote:
> > On Wed 01 Mar 2023 at 17:43:41 +0100, to...@tuxteam.de wrote:
> >
> > [...]
> >
> > > In a pinch, you can "sudo apt-get clean", which purges the APT
> > > package cache,
On Wed 01 Mar 2023 at 13:33:32 -0500, Greg Wooledge wrote:
> On Wed, Mar 01, 2023 at 06:12:09PM +, Brian wrote:
> > On Wed 01 Mar 2023 at 17:43:41 +0100, to...@tuxteam.de wrote:
> >
> > [...]
> >
> > > In a pinch, you can "sudo apt-get clean", which purges the APT
> > > package cache, which
On Wed 01 Mar 2023 at 19:48:59 +, Joe wrote:
> On Wed, 1 Mar 2023 18:12:09 +
> Brian wrote:
>
> > On Wed 01 Mar 2023 at 17:43:41 +0100, to...@tuxteam.de wrote:
> >
> > [...]
> >
> > > In a pinch, you can "sudo apt-get clean", which purges the APT
> > > package cache, which lives in
On Wed, Mar 01, 2023 at 07:53:34PM +, Joe wrote:
> On Wed, 1 Mar 2023 13:33:32 -0500
> Greg Wooledge wrote:
> > By default, "apt" removes the .deb files
> > from /var/cache/apt/archives/ after installing them, but "apt-get"
> > does not. For other programs, who knows.
>
> I've just asked
On Wed, 1 Mar 2023 13:33:32 -0500
Greg Wooledge wrote:
> On Wed, Mar 01, 2023 at 06:12:09PM +, Brian wrote:
> > On Wed 01 Mar 2023 at 17:43:41 +0100, to...@tuxteam.de wrote:
> >
> > [...]
> >
> > > In a pinch, you can "sudo apt-get clean", which purges the APT
> > > package cache, which
Hello,
On Wed, Mar 01, 2023 at 07:53:19PM +0100, Nicolas George wrote:
> Andy Smith (12023-03-01):
> > > /dev/nvme0n1p2 23G 21G 966M 96% /
> > > /dev/nvme0n1p6 267M 83M 166M 34% /boot
> > > /dev/nvme0n1p1 511M 5.8M 506M 2% /boot/efi
> > > /dev/nvme0n1p3 9.1G 3.2G 5.5G 37% /var
On Wed, 1 Mar 2023 18:12:09 +
Brian wrote:
> On Wed 01 Mar 2023 at 17:43:41 +0100, to...@tuxteam.de wrote:
>
> [...]
>
> > In a pinch, you can "sudo apt-get clean", which purges the APT
> > package cache, which lives in /var. You didn't show us /var,
> > which might be interesting too
Andy Smith (12023-03-01):
> > /dev/nvme0n1p2 23G 21G 966M 96% /
> > /dev/nvme0n1p6 267M 83M 166M 34% /boot
> > /dev/nvme0n1p1 511M 5.8M 506M 2% /boot/efi
> > /dev/nvme0n1p3 9.1G 3.2G 5.5G 37% /var
> > /dev/nvme0n1p5 1.8G 14M 1.7G 1% /tmp
> > /dev/nvme0n1p7 630G 116G
On Wed, Mar 01, 2023 at 06:12:09PM +, Brian wrote:
> On Wed 01 Mar 2023 at 17:43:41 +0100, to...@tuxteam.de wrote:
>
> [...]
>
> > In a pinch, you can "sudo apt-get clean", which purges the APT
> > package cache, which lives in /var. You didn't show us /var,
> > which might be interesting
On Wed, Mar 01, 2023 at 06:12:09PM +, Brian wrote:
> On Wed 01 Mar 2023 at 17:43:41 +0100, to...@tuxteam.de wrote:
>
> [...]
>
> > In a pinch, you can "sudo apt-get clean", which purges the APT
> > package cache, which lives in /var. You didn't show us /var,
> > which might be interesting
On Wed 01 Mar 2023 at 17:43:41 +0100, to...@tuxteam.de wrote:
[...]
> In a pinch, you can "sudo apt-get clean", which purges the APT
> package cache, which lives in /var. You didn't show us /var,
> which might be interesting too (/var/log, in case some logs
> aren't rotated properly?)
There
Hi,
On Wed, Mar 01, 2023 at 02:35:17PM +0100, lina wrote:
> My / is almost full.
>
> # df -h
> Filesystem Size Used Avail Use% Mounted on
> udev126G 0 126G 0% /dev
> tmpfs26G 2.3M 26G 1% /run
> /dev/nvme0n1p2 23G 21G
On 2023-03-01 at 09:15, Jochen Spieker wrote:
> lina:
>
>> My / is almost full.
>>
>> # df -h
>> Filesystem Size Used Avail Use% Mounted on
>> udev126G 0 126G 0% /dev
>> tmpfs26G 2.3M 26G 1% /run
>>
On Wed, Mar 01, 2023 at 02:35:17PM +0100, lina wrote:
> Hi,
>
> My / is almost full.
>
> # df -h
> Filesystem Size Used Avail Use% Mounted on
> udev126G 0 126G 0% /dev
> tmpfs26G 2.3M 26G 1% /run
> /dev/nvme0n1p2 23G
lina wrote:
> Filesystem Size Used Avail Use% Mounted on
[...]
> /dev/nvme0n1p2 23G 21G 966M 96% /
> /dev/nvme0n1p3 9.1G 3.2G 5.5G 37% /var
> /dev/nvme0n1p5 1.8G 14M 1.7G 1% /tmp
> /dev/nvme0n1p7 630G 116G 482G 20% /home
[...]
> I have done some purging already.
> :/usr#
lina:
>
> My / is almost full.
>
> # df -h
> Filesystem Size Used Avail Use% Mounted on
> udev126G 0 126G 0% /dev
> tmpfs26G 2.3M 26G 1% /run
> /dev/nvme0n1p2 23G 21G 966M 96% /
> tmpfs 126G 15M
Hi,
My / is almost full.
# df -h
Filesystem Size Used Avail Use% Mounted on
udev126G 0 126G 0% /dev
tmpfs26G 2.3M 26G 1% /run
/dev/nvme0n1p2 23G 21G 966M 96% /
tmpfs 126G 15M 126G 1% /dev/shm
tmpfs 5.0M 4.0K 5.0M 1
On Sun, Nov 13, 2022 at 09:56:21AM +, jindam, vani wrote:
> i have only deb http://deb.debian.org/debian bullseye main contrib non-free
> in my sources.list.
>
> does apt upgrade & full-upgrade packages from Security Updates (Debian
> Security Advisories (DSA))?
&g
On Sun, Nov 13, 2022 at 09:56:21AM +, jindam, vani wrote:
> i have only deb http://deb.debian.org/debian bullseye main contrib non-free
> in my sources.list.
>
> does apt upgrade & full-upgrade packages from Security Updates (Debian
> Security Advisories (DSA))?
i have only deb http://deb.debian.org/debian bullseye main contrib non-free in
my sources.list.
does apt upgrade & full-upgrade packages from Security Updates (Debian Security
Advisories (DSA))?
which is correct?
deb http://security.debian.org/debian-security bullseye-security main con
On Tue 06 Sep 2022 at 16:32:30 +, jindam, vani wrote:
> i want to install gv from experimental.
> bug if new version is released in
> unstable, will apt full-upgrade will
> install from unstable?
Yes.
> my plan: enable experimental repo on
> sources.list. update my ex
i want to install gv from experimental.
bug if new version is released in
unstable, will apt full-upgrade will
install from unstable?
my plan: enable experimental repo on
sources.list. update my existing gv
using apt -t experimental install gv
regards,
jindam, vani
Am So., 14. Aug. 2022 um 16:42 Uhr schrieb Reco :
> whois, geoiplookup, even https://bgp.he.net .
> Whatever works, basically.
> Last one is my favorite as it shows all IP blocks assigned to AS.
> Really helpful with spammer nests such as outlook.com (AS8075) or
> DigitalOcean (AS14061).
>
> > Is
On 8/14/22, Matthias Böttcher wrote:
> Am So., 14. Aug. 2022 um 09:51 Uhr schrieb Reco :
>
>> Personally I don't use fail2ban for sshd. Because why bother with
>> userspace (written in python too, yuck) if the kernel does the same job?
>> I.e. block M$ AS, China Telecom AS and maybe add Eastern
On Sun, 14 Aug 2022 16:07:03 +0200
Matthias Böttcher wrote:
> Am So., 14. Aug. 2022 um 09:51 Uhr schrieb Reco
> :
>
> > Personally I don't use fail2ban for sshd. Because why bother with
> > userspace (written in python too, yuck) if the kernel does the same
> > job? I.e. block M$ AS, China
Hi.
On Sun, Aug 14, 2022 at 04:07:03PM +0200, Matthias Böttcher wrote:
> how do I block these ip ranges?
The usual way.
iptables -I INPUT -s -p tcp --dport 22 \
-m conntrack --ctstate NEW -j DROP
or, if the source IP is an actual IPv6 (a rare thing in my experience):
Am So., 14. Aug. 2022 um 09:51 Uhr schrieb Reco :
> Personally I don't use fail2ban for sshd. Because why bother with
> userspace (written in python too, yuck) if the kernel does the same job?
> I.e. block M$ AS, China Telecom AS and maybe add Eastern Europe to the
> mix, and you've just reduced
Hi.
On Sun, Aug 14, 2022 at 09:16:25AM -0400, Stefan Monnier wrote:
> > In fact, I'd restrict allowed SSH algorithms like this:
> >
> > Ciphers chacha20-poly1...@openssh.com,aes256-...@openssh.com
> > MACs
> >
Hi.
On Sun, Aug 14, 2022 at 08:57:47AM +0200, Maurizio Caloro wrote:
> Thanks for you answer, yes add aggressive to mode, restart services and add
> to ssh_config
>
> Host *
> HostKeyAlgorithms +ssh-rsa,ssh-dss
> PubkeyAcceptedKeyTypes +ssh-rsa,ssh-dss
Please do not do this
On Sat, Aug 13, 2022 at 07:42:28PM +0200, Maurizio Caloro wrote:
>As /etc/fail2ban/filter.d/sshd.conf shows, "no matching host key type"
>messages are specifically ignored by Mode=normal.
>Try setting Mode=aggressive, it should catch those.
>
>Of course, DROPping ssh connections from AS28594
Hi.
On Sat, Aug 13, 2022 at 07:42:28PM +0200, Maurizio Caloro wrote:
> how I can disable this?, I try solution with failban, but this want be
> help!?
>
> [sshd]
> Enable = true
> Mode = normal
As /etc/fail2ban/filter.d/sshd.conf shows, "no matching host key type"
messages are
every 2-3 second this log will by appair inside auth log, and i cant place
this correctly from where this come?
Aug 13 19:25:26 Cruscotto sshd[257257]: Unable to negotiate with
200.218.251.153 port 34480: no matching host key type found. Their offer:
p de mi lan por ej la 192.168.200.3 darle acceso
> ainternet
> > full y que no tenga nada que ver con el proxy, es para que baje
> > actualizaciones y todo para servidores etc.
> >
> > puede ser así
> >
> > Ahh la ip real par el proxy por ej 200.55.55.3
> >
> > iptables -A INPUT -s 192.168.200.3 -j ACCEPT
> >
> > ?? Acepto toda ayuda
> >
> >
> >
> >
>
>
https://wiki.archlinux.org/title/Iptables_(Espa%C3%B1ol)
El lun, 20 jun 2022 a las 23:03, Luis D. Alvarez Navarro
() escribió:
>
>
> buenas a todos
>
> Necesito que me aclaren esto soy nuevo e esto de iptables.
> Necesito a una ip de mi lan por ej la 192.168.200.3 darle acceso
buenas a todos
Necesito que me aclaren esto soy nuevo e esto de iptables.
Necesito a una ip de mi lan por ej la 192.168.200.3 darle acceso ainternet
full y que no tenga nada que ver con el proxy, es para que baje
actualizaciones y todo para servidores etc.
puede ser así
Ahh la ip real par el
Hi,
Joseph wrote:
> > Question: does
> > "debian-11.0.0-amd64-xfce-CD-1.iso" < 700 MB
> > exist?
Andrew M.A. Cater and Steve McIntyre wrote:
> No [because too fat for a 650 MB CD]
It's not the first time that this came up.
My best idea for making a smaller ISO with XFCE is in
Sent from my iPhone
> Large unneeded files can be deleted with "rm".
This is what I ended up doing. The version 25 was in currently use and I
rm'ed all the old version files.
That worked, but I needed to do the same when version 31 appeared.
Fortunately the new version will get into use so rm will work.
Maybe
On Sun 01 Aug 2021 at 21:55:15 (+0200), Kamil Jońca wrote:
> David Christensen writes:
>
> [...]
> >
> > A 500 GB boot partition would be enough for several kernels, etc., on
> > Debian 10 amd64.
>
> OP wrote about 500 _M_ bytes (0.5G), and I can confirm, this is rather
> little, when trying
On 8/1/21 12:55 PM, Kamil Jońca wrote:
David Christensen writes:
[...]
A 500 GB boot partition would be enough for several kernels, etc., on
Debian 10 amd64.
OP wrote about 500 _M_ bytes (0.5G),
Please see:
> On 8/1/21 3:29 PM, David Christensen wrote:
>> I see a typo in my post --
David Christensen writes:
[...]
>
> A 500 GB boot partition would be enough for several kernels, etc., on
> Debian 10 amd64.
OP wrote about 500 _M_ bytes (0.5G), and I can confirm, this is rather
little, when trying updating kernels.
KJ
--
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html
Sorry, Stefan. This was supposed to go to the list.
On 8/2/21 11:02 PM, Marc Shapiro wrote:
On 8/1/21 9:33 PM, Stefan Monnier wrote:
So really think hard before splitting off a filesystem outside of
volume management. I believe it is more likely to cause problems
than it is to avoid
On 8/2/21 12:47 PM, Greg Wooledge wrote:
On Mon, Aug 02, 2021 at 12:43:27PM -0700, David Christensen wrote:
I'd rather not install dracut.
Me too. So why not use lsinitramfs -l ? Why keep reinventing the wheel?
unicorn:~$ lsinitramfs -l /boot/initrd.img-5.10.0-8-amd64 | head -12
drwxr-xr-x
On Mon, Aug 02, 2021 at 12:43:27PM -0700, David Christensen wrote:
> I'd rather not install dracut.
Me too. So why not use lsinitramfs -l ? Why keep reinventing the wheel?
unicorn:~$ lsinitramfs -l /boot/initrd.img-5.10.0-8-amd64 | head -12
drwxr-xr-x 2 root root0 Apr 25
On 8/2/21 11:29 AM, Greg Wooledge wrote:
On Mon, Aug 02, 2021 at 11:11:11AM -0700, David Christensen wrote:
Please post your console session showing how you created
initrd.img-5.10.0-8-amd64.txt.gz.
I didn't. It was created automatically when I installed dracut-core.
Prior to that, it was
-17-amd64 | cpio -i -d -H newc
> > > --no-absolute-filenames
> > > 246741 blocks
> >
> > That may not extract the full content of the initrd. It only reads
> > one of the concatenated CPIO archives. Also, the first archive may not
> > be gzipped. Also also, h
On 8/1/21 3:51 PM, Greg Wooledge wrote:
On Sun, Aug 01, 2021 at 03:29:07PM -0700, David Christensen wrote:
2021-08-01 13:52:37 root@dipsy ~
# gunzip -c /boot/initrd.img-4.19.0-17-amd64 | cpio -i -d -H newc
--no-absolute-filenames
246741 blocks
That may not extract the full content
B is concerned.
> Large unneeded files can be deleted with "rm". It's rough but pretty
> much the only option if the package manager can't work anymore on a full
> partition. I would use "rm" to delete the oldest not running kernel and
> initrd file and update the ke
On Sun 01 Aug 2021 at 13:21:11 (+0300), Ilkka Huotari wrote:
> Thanks. I should have said, that also apt-get autoremove fails:
>
> $ sudo apt-get autoremove
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> 0 upgraded, 0 newly installed, 0 to
On 01/08/2021 23:51, Greg Wooledge wrote:
> On Sun, Aug 01, 2021 at 03:29:07PM -0700, David Christensen wrote:
>> 2021-08-01 13:52:37 root@dipsy ~
>> # file /boot/initrd.img-4.19.0-17-amd64
>> /boot/initrd.img-4.19.0-17-amd64: gzip compressed data, last modified: Sun
>> Jul 25 19:43:38 2021, from
> So really think hard before splitting off a filesystem outside of
> volume management. I believe it is more likely to cause problems
> than it is to avoid problems.
All my machines have a separate /boot partition (and everything
else in LVM). These are all "historical accidents", because at
kernel is compiled with debugging
symbols. I can't tell if this is the case with the original poster.
Large unneeded files can be deleted with "rm". It's rough but pretty
much the only option if the package manager can't work anymore on a full
partition. I would use "rm" to delete t
On Mon, 2 Aug 2021 at 08:33, Andy Smith wrote:
> At this point there will probably be some people who consider
> themselves veterans saying that one must absolutely split things off
> because of various reasons like differing mount options being
> desirable, ability to re-use contents of /home
trd image is that size.
And maybe you've only got one. You appear not to have any microcode
in yours. But other people will generally not have just one.)
> # gunzip -c /boot/initrd.img-4.19.0-17-amd64 | cpio -i -d -H newc
> --no-absolute-filenames
> 246741 blocks
That may not extract
Hello,
OP: You are pretty safe deleting (rm) vmlinuz* and initrd* things
from /boot that are related to any kernels you aren't actually
booted into at the time. That can give you back enough space to let
apt finish what it wants to do. Just remember to do:
# update-initramfs -u -k all
101 - 200 of 1785 matches
Mail list logo
