2FA for web logins

Y

yaboc

New Member
Nov 23, 2017
26
2
3
35
Hi,
Is there a way to enable 2FA for web login (code on app/sent via email) ? Don't see it in the official documentation, so I'm using a reverse proxy with a pin for now.
Also what would be the restore process in case of failures/upgrade issues in order to avoid db corruption, etc? Both of my instances (HA) are LXCs and backed up with Proxmox backup. Would restoring that cause issues?
thanks
 
Last edited:
open this file:
Code: 
/var/www/fspbx/config/fortify.php

Uncomment this line at the end of the file
Code: 
'email-challenge',

then run
Code: 
cd /var/www/fspbx
php artisan config:cache

Next time you log in, you will be prompted for a 2FA code that will be emailed to you.
 
  • Like
Reactions: yaboc
@ja133 you are using Proxmox. Do you have an idea what the restore process would look like? My guess is that DB replication will have to be manually restored. Possibly file replication too (but this one might actually survive it better)
 
  • Like
Reactions: yaboc
Restores are straightforward

If you use DB replication you just need to get that re-established with the new IPs and/or with the most up to date database information
 
  • Like
Reactions: yaboc
thank you @pbxgeek that works great! Is there a way to edit 2FA email template to include some custom wording?
@ja133 in HA situation if i restore either ACTIVE or STANDBY node (from a backup so no ip changes etc), wouldn't it just re-establish connection automatically (IP/DB) using the most up to date db data from the node that remained ON while the other was down/being restored ?
 
Last edited:
In theory it should although I have not tested that. If I take a snapshot of my instance right now without suspending PG replication, and in an hour from now I restore that snapshot, in the last 60 minutes there would have been, at minimum, CDR transactions that took place. If the database re-syncs up with the other node, I can bet you anything that those missing CDR reports that took place while the PG connection was active will not be restored. Reason is that when the postgres link goes down, the node with the data leaves a mark of the last copied data. Since the server was not marked offline while you were taking a snapshot of your server, PG thinks that it successfully copied over the data.
 
  • Like
Reactions: yaboc
ja133 said:
In theory it should although I have not tested that. If I take a snapshot of my instance right now without suspending PG replication, and in an hour from now I restore that snapshot, in the last 60 minutes there would have been, at minimum, CDR transactions that took place. If the database re-syncs up with the other node, I can bet you anything that those missing CDR reports that took place while the PG connection was active will not be restored. Reason is that when the postgres link goes down, the node with the data leaves a mark of the last copied data. Since the server was not marked offline while you were taking a snapshot of your server, PG thinks that it successfully copied over the data.
Click to expand...
That makes sense. i have to read up on pg bidirectional replication. So it's just a matter of disabling PG replication on the node that's active and has up to date db data and once the restore of the node that has 1hr old db data is completed re-enable it? I appreciate you explaining it to me.
 
Yes. Disable PG replication on both nodes. Take your snapshot. Restore. Re enable replication.

The command, off my head, is: alter subscription <subscription name> disable;
 
  • Like
Reactions: yaboc
ja133 said:
Yes. Disable PG replication on both nodes. Take your snapshot. Restore. Re enable replication.

The command, off my head, is: alter subscription <subscription name> disable;
Click to expand...
Sorry to be asking so many questions, but in case of daily backups this would have to be done for each node.
Are you using proxmox backup server or vzdump to backup your proxmox containers? and is this something that you've scripted ? i found this
which hopefully can disable/reenable replication on both nodes and would have to be done for both containers on every backup.
 
No, it wouldnt make sense to have to pause replication every time you wanted to back up. That wouldnt be ideal practice.

Proxmox images are for disaster recoveries or scheduled maintenances

That said, if you are performing scheduled maintenance and need to move things around, that’s one thing. In the event of a disaster recovery where you need to restore an image due to some sort of an emergency, the best approach is to wipe the database on that node and get it downloaded fresh from the node with the data

I am not using PBS, I am transferring the vzdump file to a central backup server that we have
 
  • Like
Reactions: yaboc
@yaboc, before going too deep, remember that FS PBX performs nightly backups of its database and key data. You can enable or disable this in the Default Settings under Scheduled Jobs. This backed-up data is useful for disaster recovery purposes. Additionally, you might consider moving it off-site for added security. I haven't needed to restore these backups in years, but having them available is reassuring. A high-availability (HA) environment by itself greatly benefits daily server operations and makes it simple to launch a new instance when needed.
 
@pbxgeek thanks for detailed info.
i went into /var/backups/fspbx and only saw some files that didn't look like back up files so i ran the php artisan app:backup in /var/www/fspbx and that produced
-rw-r--r-- 1 root root 147M Jan 6 20:33 backup_2026-01-07.tgz
drwxr-xr-x 2 root root 4.0K Jan 6 20:33 postgresql
i'll check if that gets ran automatically from now on although the backup setting was set to True and crontab entry is present but i had to run it manually to get the files above. as always your help is invaluable! thank you
 
Should be running daily if enabled and the correct crontab entry is present (gets installed with FS PBX). You may need to check some logs for why it doesn't.
 
  • Like
Reactions: yaboc
You must log in or register to reply here.
Top Bottom