[CentOS] Centos/RHEL 8 gnome drive/usb icons

2021-03-31 Thread R C

Hello,


In Centos 7 (and RHEL 7)  when one would connect a drive, or USB stick, 
an icon wold appear on the (gnome) desktop.



Is that just something that was turned off (like anything else)?  or is 
that not around anymore?



If it is, how can it be turnd on again, that when logged in, and a drive 
is connected an icon shows up on the desktop again?



thanks,


Ron

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Migrating to nvme and expand

2021-03-31 Thread Jerry Geis
> Are you using the MD devices as Physical Volumes ?If ues, then create a
PV from that NVME and then pvmove.

>Best Regards,Strahil Nikolov

more /proc/mdstat
Personalities : [raid1]
md126 : active raid1 sdb3[2] sda3[0]
  1866465280 blocks super 1.2 [2/2] [UU]
  bitmap: 4/14 pages [16KB], 65536KB chunk

md127 : active raid1 sdb1[0] sda1[2]
  52461440 blocks super 1.0 [2/2] [UU]
  bitmap: 1/1 pages [4KB], 65536KB chunk

This is the mdstat.  the md126 just has /dev/sdb3 and /dev/sda3 - and
md127 has the /dev/sdb1 and /dev/sda1


Thanks

Jerry
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Migrating to nvme and expand

2021-03-31 Thread Strahil Nikolov via CentOS
Are you using the MD devices as Physical Volumes ?If ues, then create a PV from 
that NVME and then pvmove.
Best Regards,Strahil Nikolov
 
 
  On Wed, Mar 31, 2021 at 21:16, Jerry Geis wrote:   I 
have older SATA disks (2 of them size 2T) in a software raid config
running CentOS 7.

/dev/md127 is / and xfs
/dev/sda2 is swap
/dev/md126 is /home and xfs

I desire to get a new (single) NVME 4T disk.

What is the correct way to copy the software raid to a single "new" NVME
disk ?
then expand the /home file system to All the remaining space?

Thanks,

Jerry
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
  
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Problem with mail server: stop flooding with fail2ban ?

2021-03-31 Thread David Hrbáč
Hello NIki,

Juste enable postfix-sasl in jail.conf:

[postfix-sasl]

filter   = postfix[mode=auth]
port = smtp,465,submission,imap,imaps,pop3,pop3s
logpath  = %(postfix_log)s
backend  = %(postfix_backend)s
enabled = true
maxretry = 3
findtime = 172800
bantime = 3600

And enable recidive too:

[recidive]

logpath  = /var/log/fail2ban.log
banaction = %(banaction_allports)s
bantime  = 1mo
findtime = 1w
enabled  = true

Add ignoreip = 127.0.0.1 and your jumpoints :)

Regards,
DH

po 29. 3. 2021 v 21:31 odesílatel Nicolas Kovacs 
napsal:

> Hi,
>
> My main mail server is running CentOS 7 with Postfix and Dovecot.
>
> Last week I was surprised to see that Postfix had some troubles on this
> machine, according to Icinga. I took a peek at the logs:
>
> # journalctl -p err
> Mar 28 04:37:02 sd-151768 postfix/smtpd[2786]: fatal: no SASL
> authentication
> mechanisms
> Mar 28 04:37:02 sd-151768 postfix/smtpd[2788]: fatal: no SASL
> authentication
> mechanisms
> Mar 28 04:37:02 sd-151768 postfix/smtpd[2790]: fatal: no SASL
> authentication
> mechanisms
> Mar 28 04:37:02 sd-151768 postfix/smtpd[2792]: fatal: no SASL
> authentication
> mechanisms
> Mar 28 04:37:02 sd-151768 postfix/smtpd[2794]: fatal: no SASL
> authentication
> mechanisms
> ...
>
> And in /var/log/maillog I found a tsunami of these:
>
> Mar 28 03:18:33 sd-151768 postfix/smtpd[29589]: warning:
> unknown[45.227.253.115]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
> Mar 28 03:18:33 sd-151768 postfix/smtpd[29589]: lost connection after AUTH
> from
> unknown[45.227.253.115]
> Mar 28 03:18:33 sd-151768 postfix/smtpd[29589]: disconnect from
> unknown[45.227.253.115]
>
> My first reaction was to manually ban the IP addresses / networks which
> caused
> the flood, using my firewall:
>
> # firewall-cmd --permanent --add-rich-rule="rule family='ipv4' source
> address='45.227.253.0/24' reject"
> # firewall-cmd --reload
>
> I'm already using fail2ban in conjunction with firewalld to prevent brute
> force
> SSH attacks.
>
> Q: can I use it in a similar configuration to stop Postfix from getting
> flooded
> and brought down to its knees?
>
> Thanks & cheers from the sunny South of France,
>
> Niki
>
> --
> Microlinux - Solutions informatiques durables
> 7, place de l'église - 30730 Montpezat
> Site : https://www.microlinux.fr
> Blog : https://blog.microlinux.fr
> Mail : i...@microlinux.fr
> Tél. : 04 66 63 10 32
> Mob. : 06 51 80 12 12
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] KVM vs. incremental remote backups

2021-03-31 Thread Nicolas Kovacs
Le 31/03/2021 à 21:35, Gionatan Danti a écrit :
> 
> Finally, I would leave the current rsnapshot backups in-place: you will simply
> copy from a virtual machine rather than from a bare metal host. I found
> rsnapshot really useful and reliable, so I suggest to continue using it even 
> if
> efficient block-level backup are taken.

First of all, thanks to everybody for your competent input.

Indeed, there's (almost) nothing wrong with Rsnapshot. It even saved me on
March 7th when my main production server crashed.

The problem with using Rsnapshot on the VM's filesystems rather than backing up
the whole VM is the time it takes to restore all the mess.

Niki

-- 
Microlinux - Solutions informatiques durables
7, place de l'église - 30730 Montpezat
Site : https://www.microlinux.fr
Blog : https://blog.microlinux.fr
Mail : i...@microlinux.fr
Tél. : 04 66 63 10 32
Mob. : 06 51 80 12 12
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] KVM vs. incremental remote backups

2021-03-31 Thread Gionatan Danti

Il 2021-03-31 14:41 Nicolas Kovacs ha scritto:

Hi,

Up until recently I've hosted all my stuff (web & mail) on a handful of 
bare

metal servers. Web applications (WordPress, OwnCloud, Dolibarr, GEPI,
Roundcube) as well as mail and a few other things were hosted mostly on 
one big

machine.

Backups for this setup were done using Rsnapshot, a nifty utility that 
combines

Rsync over SSH and hard links to make incremental backups.

This approach has become problematic, for several reasons. First, web
applications have increasingly specific and sometimes mutually 
exclusive
requirements. And second, last month I had a server crash, and even 
though I

had backups for everything, this meant quite some offline time.

So I've opted to go for KVM-based solutions, with everything split up 
over a
series of KVM guests. I wrapped my head around KVM, played around with 
it (a

lot) and now I'm more or less ready to go.

One detail is nagging me though: backups.

Let's say I have one VM that handles only DNS (base installation + 
BIND) and

one other VM that handles mail (base installation + Postfix + Dovecot).

Under the hood that's two QCOW2 images stored in 
/var/lib/libvirt/images.


With the old "bare metal" approach I could perform remote backups using 
Rsync,
so only the difference between two backups would get transferred over 
the
network. Now with KVM images it looks like every day I have to transfer 
the
whole image again. As soon as some images have lots of data on them 
(say, 100

GB for a small OwnCloud server), this quickly becomes unmanageable.

I googled around quite some time for "KVM backup best practices" and 
was a bit
puzzled to find many folks asking the same question and no real answer, 
at

least not without having to jump through burning loops.

Any suggestions ?

Niki


Hi Nicolas,
the simpler approach would be to use a filesystem which natively 
supports send/recv on another host.


You can be tempted to use btrfs, but having tested it I strongly advice 
against it: it will horribly fragments and performance will be bad even 
if disabling CoW (which, by the way, is automatically re-enabled by 
snapshots).


I currently just use ZFS on Linux and it works very well. However, using 
it in CentOS is not trouble-free and it has its own CLI and specific 
issues to be aware; so, I understand if you don't want to go down this 
rabbit hole.


The next best thing I can suggest is to use lvmthin and XFS, with 
efficient block-level copies done to another host via tools as bdsync 
[1] or blocksync [2] (of which I forked an advanced version). On the 
receiving host, you should (again) use lvmthin and XFS with periodic 
snapshots.


Finally, I would leave the current rsnapshot backups in-place: you will 
simply copy from a virtual machine rather than from a bare metal host. I 
found rsnapshot really useful and reliable, so I suggest to continue 
using it even if efficient block-level backup are taken.


Just my 2 cents.
Regards.

--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.da...@assyoma.it - i...@assyoma.it
GPG public key ID: FF5F32A8
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


[CentOS] Migrating to nvme and expand

2021-03-31 Thread Jerry Geis
I have older SATA disks (2 of them size 2T) in a software raid config
running CentOS 7.

/dev/md127 is / and xfs
/dev/sda2 is swap
/dev/md126 is /home and xfs

I desire to get a new (single) NVME 4T disk.

What is the correct way to copy the software raid to a single "new" NVME
disk ?
then expand the /home file system to All the remaining space?

Thanks,

Jerry
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] KVM vs. incremental remote backups

2021-03-31 Thread Simon Matter
> Hi,
>
> Up until recently I've hosted all my stuff (web & mail) on a handful of
> bare
> metal servers. Web applications (WordPress, OwnCloud, Dolibarr, GEPI,
> Roundcube) as well as mail and a few other things were hosted mostly on
> one big
> machine.
>
> Backups for this setup were done using Rsnapshot, a nifty utility that
> combines
> Rsync over SSH and hard links to make incremental backups.
>
> This approach has become problematic, for several reasons. First, web
> applications have increasingly specific and sometimes mutually exclusive
> requirements. And second, last month I had a server crash, and even though
> I
> had backups for everything, this meant quite some offline time.
>
> So I've opted to go for KVM-based solutions, with everything split up over
> a
> series of KVM guests. I wrapped my head around KVM, played around with it
> (a
> lot) and now I'm more or less ready to go.
>
> One detail is nagging me though: backups.
>
> Let's say I have one VM that handles only DNS (base installation + BIND)
> and
> one other VM that handles mail (base installation + Postfix + Dovecot).
>
> Under the hood that's two QCOW2 images stored in /var/lib/libvirt/images.
>
> With the old "bare metal" approach I could perform remote backups using
> Rsync,

We're doing rsnapshot based backups for everything, VMs and bare metal
systems. We don't care about KVM image files for backups.

When a new host is included in the backup, we first do a hard link based
copy on the backup server of another, similar server. Then, the most of
the OS is already there on the backup server and real backup consumes only
little space.

The only problem we had with rsnapshot is that rsync by default can't
handle a lot of hard links. We're now using our own build of rsync 3.2.3
with --max-alloc=0 and multi million hard links are not a problem anymore.

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] KVM vs. incremental remote backups

2021-03-31 Thread Leon Fauster via CentOS

On 31.03.21 14:41, Nicolas Kovacs wrote:

Hi,

Up until recently I've hosted all my stuff (web & mail) on a handful of bare
metal servers. Web applications (WordPress, OwnCloud, Dolibarr, GEPI,
Roundcube) as well as mail and a few other things were hosted mostly on one big
machine.

Backups for this setup were done using Rsnapshot, a nifty utility that combines
Rsync over SSH and hard links to make incremental backups.

This approach has become problematic, for several reasons. First, web
applications have increasingly specific and sometimes mutually exclusive
requirements. And second, last month I had a server crash, and even though I
had backups for everything, this meant quite some offline time.

So I've opted to go for KVM-based solutions, with everything split up over a
series of KVM guests. I wrapped my head around KVM, played around with it (a
lot) and now I'm more or less ready to go.

One detail is nagging me though: backups.

Let's say I have one VM that handles only DNS (base installation + BIND) and
one other VM that handles mail (base installation + Postfix + Dovecot).

Under the hood that's two QCOW2 images stored in /var/lib/libvirt/images.

With the old "bare metal" approach I could perform remote backups using Rsync,
so only the difference between two backups would get transferred over the
network. Now with KVM images it looks like every day I have to transfer the
whole image again. As soon as some images have lots of data on them (say, 100
GB for a small OwnCloud server), this quickly becomes unmanageable.

I googled around quite some time for "KVM backup best practices" and was a bit
puzzled to find many folks asking the same question and no real answer, at
least not without having to jump through burning loops.

Any suggestions ?



As others pointed out - LVM would be a smart solution and BTW rsnapshot 
supports LVM snapshot backups.


If you want a raw approach against the image file, then use a 
deduplication backup tool (block based backups).


--
Leon



___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] KVM vs. incremental remote backups

2021-03-31 Thread Robert Heller


What *I* do for backing up KVM VMs is that I use LVM volumes, not QCOW2 
images.  Then I take a LVM "snapshot" volume, then mount that locally / 
readonly on the host and use tar (via Amanda).  Another option is to install 
Amanda's client on the VM itself and use Amanda to use tar (running on the VM) 
-- I use the latter to deal with VMs that have a FS that it not mountable on 
the host (usually due to ext4 version issues -- CentOS 6's mount.ext4 did not 
like Ubuntu's 18.04 ext4 fs).  I have always found using container image files 
with VMs a bit too opaque.

Since you are using QCOW2 images, you best option would be to treat the VMs 
as if they were just bare metal servers and rsync over the virtual network 
(ala 'rsync -a vmhostname:/ backupserver:/backupdisk/vmhostname_backup/') and 
not even try to backup the QCOW2 image files, except maybe once in awhile for 
"disaster" recovery purposes (eg if you need  to recreate th VM from scratch 
from a known state).



At Wed, 31 Mar 2021 14:41:09 +0200 CentOS mailing list  
wrote:

> 
> Hi,
> 
> Up until recently I've hosted all my stuff (web & mail) on a handful of bare
> metal servers. Web applications (WordPress, OwnCloud, Dolibarr, GEPI,
> Roundcube) as well as mail and a few other things were hosted mostly on one 
> big
> machine.
> 
> Backups for this setup were done using Rsnapshot, a nifty utility that 
> combines
> Rsync over SSH and hard links to make incremental backups.
> 
> This approach has become problematic, for several reasons. First, web
> applications have increasingly specific and sometimes mutually exclusive
> requirements. And second, last month I had a server crash, and even though I
> had backups for everything, this meant quite some offline time.
> 
> So I've opted to go for KVM-based solutions, with everything split up over a
> series of KVM guests. I wrapped my head around KVM, played around with it (a
> lot) and now I'm more or less ready to go.
> 
> One detail is nagging me though: backups.
> 
> Let's say I have one VM that handles only DNS (base installation + BIND) and
> one other VM that handles mail (base installation + Postfix + Dovecot).
> 
> Under the hood that's two QCOW2 images stored in /var/lib/libvirt/images.
> 
> With the old "bare metal" approach I could perform remote backups using Rsync,
> so only the difference between two backups would get transferred over the
> network. Now with KVM images it looks like every day I have to transfer the
> whole image again. As soon as some images have lots of data on them (say, 100
> GB for a small OwnCloud server), this quickly becomes unmanageable.
> 
> I googled around quite some time for "KVM backup best practices" and was a bit
> puzzled to find many folks asking the same question and no real answer, at
> least not without having to jump through burning loops.
> 
> Any suggestions ?
> 
> Niki
> 

-- 
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software-- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
hel...@deepsoft.com   -- Webhosting Services
   
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] KVM vs. incremental remote backups

2021-03-31 Thread Stephen John Smoogen
On Wed, 31 Mar 2021 at 08:41, Nicolas Kovacs  wrote:

> Hi,
>
> Up until recently I've hosted all my stuff (web & mail) on a handful of
> bare
> metal servers. Web applications (WordPress, OwnCloud, Dolibarr, GEPI,
> Roundcube) as well as mail and a few other things were hosted mostly on
> one big
> machine.
>
> Backups for this setup were done using Rsnapshot, a nifty utility that
> combines
> Rsync over SSH and hard links to make incremental backups.
>
> This approach has become problematic, for several reasons. First, web
> applications have increasingly specific and sometimes mutually exclusive
> requirements. And second, last month I had a server crash, and even though
> I
> had backups for everything, this meant quite some offline time.
>
> So I've opted to go for KVM-based solutions, with everything split up over
> a
> series of KVM guests. I wrapped my head around KVM, played around with it
> (a
> lot) and now I'm more or less ready to go.
>
> One detail is nagging me though: backups.
>
> Let's say I have one VM that handles only DNS (base installation + BIND)
> and
> one other VM that handles mail (base installation + Postfix + Dovecot).
>
> Under the hood that's two QCOW2 images stored in /var/lib/libvirt/images.
>
> With the old "bare metal" approach I could perform remote backups using
> Rsync,
> so only the difference between two backups would get transferred over the
> network. Now with KVM images it looks like every day I have to transfer the
> whole image again. As soon as some images have lots of data on them (say,
> 100
> GB for a small OwnCloud server), this quickly becomes unmanageable.
>
> I googled around quite some time for "KVM backup best practices" and was a
> bit
> puzzled to find many folks asking the same question and no real answer, at
> least not without having to jump through burning loops.
>
> Any suggestions ?
>
>
For Fedora Infrastructure we use a three prong approach
1. Kickstarts for the basic system
2. Ansible for the deployment and 'general configuration management'
3. rdiff-backup of things which ansible would not be able to bring back.

So most of our infrastructure is KVM only and the only systems we have to
kickstart by 'hand' are the bare metal. The guests are then fired off with
an ansible playbook which uses libvirt to fire up the initial guest and
kickstart from known data. Then the playbook continues and builds out the
system for the rest of the deployment. [Our guests are also usually lvm
partitions so we can use LVM tools to snapshot the system in different
ways.]

After it is done there are usually scripts which do things like do ascii
dumps of databases and such.

As you pointed out this isn't the only way to do so. Other sites have a
master qemu image for all their guests on a machine and clone that instead
of doing kickstarts for each. They also do snapshots of the images via lvm
or some other tool in order to make backups that way.

hope this helps.



> Niki
>
> --
> Microlinux - Solutions informatiques durables
> 7, place de l'église - 30730 Montpezat
> Site : https://www.microlinux.fr
> Blog : https://blog.microlinux.fr
> Mail : i...@microlinux.fr
> Tél. : 04 66 63 10 32
> Mob. : 06 51 80 12 12
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>


-- 
Stephen J Smoogen.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


[CentOS] KVM vs. incremental remote backups

2021-03-31 Thread Nicolas Kovacs
Hi,

Up until recently I've hosted all my stuff (web & mail) on a handful of bare
metal servers. Web applications (WordPress, OwnCloud, Dolibarr, GEPI,
Roundcube) as well as mail and a few other things were hosted mostly on one big
machine.

Backups for this setup were done using Rsnapshot, a nifty utility that combines
Rsync over SSH and hard links to make incremental backups.

This approach has become problematic, for several reasons. First, web
applications have increasingly specific and sometimes mutually exclusive
requirements. And second, last month I had a server crash, and even though I
had backups for everything, this meant quite some offline time.

So I've opted to go for KVM-based solutions, with everything split up over a
series of KVM guests. I wrapped my head around KVM, played around with it (a
lot) and now I'm more or less ready to go.

One detail is nagging me though: backups.

Let's say I have one VM that handles only DNS (base installation + BIND) and
one other VM that handles mail (base installation + Postfix + Dovecot).

Under the hood that's two QCOW2 images stored in /var/lib/libvirt/images.

With the old "bare metal" approach I could perform remote backups using Rsync,
so only the difference between two backups would get transferred over the
network. Now with KVM images it looks like every day I have to transfer the
whole image again. As soon as some images have lots of data on them (say, 100
GB for a small OwnCloud server), this quickly becomes unmanageable.

I googled around quite some time for "KVM backup best practices" and was a bit
puzzled to find many folks asking the same question and no real answer, at
least not without having to jump through burning loops.

Any suggestions ?

Niki

-- 
Microlinux - Solutions informatiques durables
7, place de l'église - 30730 Montpezat
Site : https://www.microlinux.fr
Blog : https://blog.microlinux.fr
Mail : i...@microlinux.fr
Tél. : 04 66 63 10 32
Mob. : 06 51 80 12 12
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] nmcli

2021-03-31 Thread Jerry Geis
Chris,

On Tue, Mar 30, 2021 at 4:41 PM Jerry Geis  wrote:

> under CentOS 7 - I use "alias" like eth1:0 for an alias network. Remove
> the file restart network - and back to normal. Now I am trying to us
> NetworkManager.
>
> I can 'add' the network fine. however - when I remove the network
> nmcli connection delete "Wired connection 2" ipv4.addr  192.168.1.58/22
>
> it remove BOTH address and removes the "Wired connection 2" config file -
> and it reverts to DHCP not the other static address I had associated with
> "Wired connection 2".
>
> how do I just remove the single ADDRESS I added as an alias ? not the
> whole thing ?
>
> Thanks
>
> Jerry
>

Thanks that was it: (the minus)

   nmcli con mod em1 -ipv4.address 10.1.1.2/24

Jerry
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Prevent Anaconda from switching root and swap partition

2021-03-31 Thread Stephen John Smoogen
On Wed, 31 Mar 2021 at 05:11, Nicolas Kovacs  wrote:

> Hi,
>
> More often than not, when installing CentOS, I choose manual partitioning
> and
> then apply the KISS principle, with a very simple partitioning scheme that
> looks more or less like this:
>
>   * /boot partition: 500 MB, ext2
>   * swap partition: equivalent to amount of RAM
>   * root partition: available space, ext4
>
> Now when I do this, Anaconda insists on switching my swap and root
> partitions,
> so instead of this:
>
>   * /dev/sda1: boot partition
>   * /dev/sda2: swap partition
>   * /dev/sda3: root partition
>
> ... I get this:
>
>   * /dev/sda1: boot partition
>   * /dev/sda2: root partition
>   * /dev/sda3: swap partition
>
> Up until now this hasn't bothered me much. But for my needs right now it
> does,
> because I need my root partition to be at the end of the disk, so it can be
> expanded later on.
>
> Anyone knows how I can prevent Anaconda from switching my root and swap
> partitions? What I'm doing right now is switching to a text console with
> Ctrl-Alt-F5, manually partition using fdisk, switch back to Anaconda and
> then
> rescan the disk, but it's quite a PITA.
>
> These are the moments where I miss the good old bone-headed Slackware
> installer. :o)
>
> Cheers,
>
>
Since you are doing manual vs kickstart, you need to do additional steps
Before you go into the disk system in the UI

Control-Alt-F2
fdisk (or gfdisk  or parted depending on your prefs and needs)
clear the disk and set it up how you want it with the types set on each
partition.
go back into the UI and do the things you wanted. have it reread the disks
and have it use the existing partitions versus anything else

Option 2 is to go into the advanced partitioning tool blivet and see if it
can be done through that.. but I think you still need to do a
'slackware/arch' setup first

-- 
Stephen J Smoogen.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Prevent Anaconda from switching root and swap partition

2021-03-31 Thread Leon Fauster via CentOS

On 31.03.21 11:30, Simon Matter wrote:

Hi,

More often than not, when installing CentOS, I choose manual partitioning
and
then apply the KISS principle, with a very simple partitioning scheme that
looks more or less like this:

   * /boot partition: 500 MB, ext2
   * swap partition: equivalent to amount of RAM
   * root partition: available space, ext4

Now when I do this, Anaconda insists on switching my swap and root
partitions,
so instead of this:

   * /dev/sda1: boot partition
   * /dev/sda2: swap partition
   * /dev/sda3: root partition

... I get this:

   * /dev/sda1: boot partition
   * /dev/sda2: root partition
   * /dev/sda3: swap partition

Up until now this hasn't bothered me much. But for my needs right now it
does,
because I need my root partition to be at the end of the disk, so it can
be
expanded later on.

Anyone knows how I can prevent Anaconda from switching my root and swap
partitions? What I'm doing right now is switching to a text console with
Ctrl-Alt-F5, manually partition using fdisk, switch back to Anaconda and
then
rescan the disk, but it's quite a PITA.


That's exactly what I wanted to suggest you :-)

I never found a better way...



I never have done that but is %pre script section not exactly the place 
for that ?


--
Leon


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Prevent Anaconda from switching root and swap partition

2021-03-31 Thread Simon Matter
> Hi,
>
> More often than not, when installing CentOS, I choose manual partitioning
> and
> then apply the KISS principle, with a very simple partitioning scheme that
> looks more or less like this:
>
>   * /boot partition: 500 MB, ext2
>   * swap partition: equivalent to amount of RAM
>   * root partition: available space, ext4
>
> Now when I do this, Anaconda insists on switching my swap and root
> partitions,
> so instead of this:
>
>   * /dev/sda1: boot partition
>   * /dev/sda2: swap partition
>   * /dev/sda3: root partition
>
> ... I get this:
>
>   * /dev/sda1: boot partition
>   * /dev/sda2: root partition
>   * /dev/sda3: swap partition
>
> Up until now this hasn't bothered me much. But for my needs right now it
> does,
> because I need my root partition to be at the end of the disk, so it can
> be
> expanded later on.
>
> Anyone knows how I can prevent Anaconda from switching my root and swap
> partitions? What I'm doing right now is switching to a text console with
> Ctrl-Alt-F5, manually partition using fdisk, switch back to Anaconda and
> then
> rescan the disk, but it's quite a PITA.

That's exactly what I wanted to suggest you :-)

I never found a better way...

Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


[CentOS] Prevent Anaconda from switching root and swap partition

2021-03-31 Thread Nicolas Kovacs
Hi,

More often than not, when installing CentOS, I choose manual partitioning and
then apply the KISS principle, with a very simple partitioning scheme that
looks more or less like this:

  * /boot partition: 500 MB, ext2
  * swap partition: equivalent to amount of RAM
  * root partition: available space, ext4

Now when I do this, Anaconda insists on switching my swap and root partitions,
so instead of this:

  * /dev/sda1: boot partition
  * /dev/sda2: swap partition
  * /dev/sda3: root partition

... I get this:

  * /dev/sda1: boot partition
  * /dev/sda2: root partition
  * /dev/sda3: swap partition

Up until now this hasn't bothered me much. But for my needs right now it does,
because I need my root partition to be at the end of the disk, so it can be
expanded later on.

Anyone knows how I can prevent Anaconda from switching my root and swap
partitions? What I'm doing right now is switching to a text console with
Ctrl-Alt-F5, manually partition using fdisk, switch back to Anaconda and then
rescan the disk, but it's quite a PITA.

These are the moments where I miss the good old bone-headed Slackware
installer. :o)

Cheers,

Niki
-- 
Microlinux - Solutions informatiques durables
7, place de l'église - 30730 Montpezat
Site : https://www.microlinux.fr
Blog : https://blog.microlinux.fr
Mail : i...@microlinux.fr
Tél. : 04 66 63 10 32
Mob. : 06 51 80 12 12
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Problem with mail server: stop flooding with fail2ban ?

2021-03-31 Thread Jamie Burchell
Sorry, re-read your question and realise my suggestion would only help you get 
SASL authentication working.

> On 31 Mar 2021, at 09:19, Jamie Burchell  wrote:
> 
> I'm pretty sure I encountered this and needed to yum install 
> cyrus-sasl-plain to resolve it.
> 
>> On 29 Mar 2021, at 20:31, Nicolas Kovacs  wrote:
>> 
>> Hi,
>> 
>> My main mail server is running CentOS 7 with Postfix and Dovecot.
>> 
>> Last week I was surprised to see that Postfix had some troubles on this
>> machine, according to Icinga. I took a peek at the logs:
>> 
>> # journalctl -p err
>> Mar 28 04:37:02 sd-151768 postfix/smtpd[2786]: fatal: no SASL authentication
>> mechanisms
>> Mar 28 04:37:02 sd-151768 postfix/smtpd[2788]: fatal: no SASL authentication
>> mechanisms
>> Mar 28 04:37:02 sd-151768 postfix/smtpd[2790]: fatal: no SASL authentication
>> mechanisms
>> Mar 28 04:37:02 sd-151768 postfix/smtpd[2792]: fatal: no SASL authentication
>> mechanisms
>> Mar 28 04:37:02 sd-151768 postfix/smtpd[2794]: fatal: no SASL authentication
>> mechanisms
>> ...
>> 
>> And in /var/log/maillog I found a tsunami of these:
>> 
>> Mar 28 03:18:33 sd-151768 postfix/smtpd[29589]: warning:
>> unknown[45.227.253.115]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
>> Mar 28 03:18:33 sd-151768 postfix/smtpd[29589]: lost connection after AUTH 
>> from
>> unknown[45.227.253.115]
>> Mar 28 03:18:33 sd-151768 postfix/smtpd[29589]: disconnect from
>> unknown[45.227.253.115]
>> 
>> My first reaction was to manually ban the IP addresses / networks which 
>> caused
>> the flood, using my firewall:
>> 
>> # firewall-cmd --permanent --add-rich-rule="rule family='ipv4' source
>> address='45.227.253.0/24' reject"
>> # firewall-cmd --reload
>> 
>> I'm already using fail2ban in conjunction with firewalld to prevent brute 
>> force
>> SSH attacks.
>> 
>> Q: can I use it in a similar configuration to stop Postfix from getting 
>> flooded
>> and brought down to its knees?
>> 
>> Thanks & cheers from the sunny South of France,
>> 
>> Niki
>> 
>> -- 
>> Microlinux - Solutions informatiques durables
>> 7, place de l'église - 30730 Montpezat
>> Site : https://www.microlinux.fr
>> Blog : https://blog.microlinux.fr
>> Mail : i...@microlinux.fr
>> Tél. : 04 66 63 10 32
>> Mob. : 06 51 80 12 12
>> ___
>> CentOS mailing list
>> CentOS@centos.org
>> https://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Problem with mail server: stop flooding with fail2ban ?

2021-03-31 Thread Jamie Burchell
I'm pretty sure I encountered this and needed to yum install cyrus-sasl-plain 
to resolve it.

> On 29 Mar 2021, at 20:31, Nicolas Kovacs  wrote:
> 
> Hi,
> 
> My main mail server is running CentOS 7 with Postfix and Dovecot.
> 
> Last week I was surprised to see that Postfix had some troubles on this
> machine, according to Icinga. I took a peek at the logs:
> 
> # journalctl -p err
> Mar 28 04:37:02 sd-151768 postfix/smtpd[2786]: fatal: no SASL authentication
> mechanisms
> Mar 28 04:37:02 sd-151768 postfix/smtpd[2788]: fatal: no SASL authentication
> mechanisms
> Mar 28 04:37:02 sd-151768 postfix/smtpd[2790]: fatal: no SASL authentication
> mechanisms
> Mar 28 04:37:02 sd-151768 postfix/smtpd[2792]: fatal: no SASL authentication
> mechanisms
> Mar 28 04:37:02 sd-151768 postfix/smtpd[2794]: fatal: no SASL authentication
> mechanisms
> ...
> 
> And in /var/log/maillog I found a tsunami of these:
> 
> Mar 28 03:18:33 sd-151768 postfix/smtpd[29589]: warning:
> unknown[45.227.253.115]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
> Mar 28 03:18:33 sd-151768 postfix/smtpd[29589]: lost connection after AUTH 
> from
> unknown[45.227.253.115]
> Mar 28 03:18:33 sd-151768 postfix/smtpd[29589]: disconnect from
> unknown[45.227.253.115]
> 
> My first reaction was to manually ban the IP addresses / networks which caused
> the flood, using my firewall:
> 
> # firewall-cmd --permanent --add-rich-rule="rule family='ipv4' source
> address='45.227.253.0/24' reject"
> # firewall-cmd --reload
> 
> I'm already using fail2ban in conjunction with firewalld to prevent brute 
> force
> SSH attacks.
> 
> Q: can I use it in a similar configuration to stop Postfix from getting 
> flooded
> and brought down to its knees?
> 
> Thanks & cheers from the sunny South of France,
> 
> Niki
> 
> -- 
> Microlinux - Solutions informatiques durables
> 7, place de l'église - 30730 Montpezat
> Site : https://www.microlinux.fr
> Blog : https://blog.microlinux.fr
> Mail : i...@microlinux.fr
> Tél. : 04 66 63 10 32
> Mob. : 06 51 80 12 12
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos