How to Repair Verify Disk Permissions in OS X El Capitan

Open the Terminal application (found in /Applications/Utilities/) and use the following syntax to verify a volumes permissions, this will verify the default root volume of a Mac:

sudo /usr/libexec/repair_packages --verify --standard-pkgs /

If you want to verify permissions on a different drive, specify the volume rather than “/”

The command will run and either show permissions that differ, or nothing, depending on what’s found. Not surprisingly, you’ll likely find some variation of permissions that differs, looking something like:

Permissions differ on "usr/libexec/cups/cgi-bin", should be drwxr-xr-x , they are dr-xr-xr-x .
Permissions differ on "usr/libexec/cups/daemon", should be drwxr-xr-x , they are dr-xr-xr-x .
Permissions differ on "usr/libexec/cups/driver", should be drwxr-xr-x , they are dr-xr-xr-x .
Permissions differ on "usr/libexec/cups/monitor", should be drwxr-xr-x , they are dr-xr-xr-x .

How to Repair Disk Permissions in OS X El Capitan from Command Line

Assuming permissions have been found which differ and you’d like to repair them, replace the –verify flag with –repair, and again point the command at the same volume

sudo /usr/libexec/repair_packages --repair --standard-pkgs --volume /

Repairing permissions may take a while, just like it did from Disk Utility.

Verify and repair disk permissions in OS X from command line

If you execute the repair_packages command without sudo and with no specifications or flags, you’ll get a simple help guide instead:

$ /usr/libexec/repair_packages
Usage: repair_packages [ARGUMENTS]...
Commands:
--help Print this usage guide.
--list-standard-pkgs Display the package ids in the standard set.
--verify Verify permissions on files in the specified package(s).
--repair Repair permissions on files in the specified package(s).
Options:
--pkg PKGID Verify or repair the package PKGID.
--standard-pkgs Verify or repair the standard set of packages.
--volume PATH Perform all operations on the specified volume.
--output-format # Print progress info using a special output format.
--debug Print debuging information while running.

As suggested, this is not really something that should be run on a regular basis as any part of Mac maintenance routine, and it’s rarely necessary, which is likely why Apple pulled it from the Disk Utility application.

By the way, earlier releases of OS X also have a command line approach to repairing disk permissions, but it’s handled through the Disk Utility command line tool instead.
Source: OSXDaily

Patton SIP Gateway at remote site using 3CX SBC

This guide will demonstrate the use of a Patton SIP Gateway to Analog FXO/FXS connected to 3CX via the SBC gateway.

The use cases for this are where the 3CX instance is hosted, but it needs access to FXO or FXS connections at the client office. It can also be used in scenarios where the client has branch offices with FXO or FXS connection requirements within the 3CX system at head office.

Follow the setup guide for the Patton gateways located below:
FXO: https://www.3cx.com/voip-gateways/patton-smartnode-sn4112/
(for this guide, I used the FXO version)
FXS: https://www.3cx.com/voip-gateways/patton-smartnode-sn4112-fxs/
But don’t follow the whole guide as we need to make alterations to the config file prior to uploading it to the Patton appliance.

Basically, we need to create the SIP Gateway entity in 3CX, export the config, modify it, and upload into the gateway – do the following:

3CX Management > SIP Trunks > Add Gateway
Select Brand: Patton
Select appropriate model or type
Enter the number of ports the device has (not the number you intend to use – must be total)
Enter the main trunk number

Next, enter the local IP address of the device (must be static or DHCP reservation)
Subnet mask: applicable to the gateway’s local network
Tone Selection region: Australia
Number or SIM calls: this is where you specify the number of lines you will be using
Number of physical PSTN ports: should be pre-populated from earlier.

Under options, Dial Delay: Wait for Dial Tone
Hit OK, then go back into the SIP Gateway in 3cx, next to the blue OK button is Generate device config
This will open a new tab or window into the Patton’s import screen and download the config file to your local computer
Open the config in Notepad++ or similar
Locate the 3CX’s local IP address – using find & replace to replace them all with the SBC’s local IP address
Save and import this config into the Patton gateway, reload, wait, and it should be visible to 3CX once loaded & connected behind the SBC.

LG-NORTEL iPECS-300 Maintenance Password Reset

Connect to the PBX using a 9-pin female to 9-pin female serial console cable.

Use Putty or similar to console in with 115200,8,N,1

Press Enter to initialise the console

Password to enter console mode is: jannie

Reset the maintenance password using:

password man <your new maint password here>

Now you should be able to login to the web interface using the maintenance account and the password set on the end of the terminal command.

Extra notes: https://www.tek-tips.com/viewthread.cfm?qid=1783908

 

3CX Monitoring in PRTG

This script is designed for Debian Linux based 3CX deployments that need to be monitored in PRTG.

Create the scripts in

/var/prtg/scripts

Call the script: 3cxstatuscheck.pl

Make it executable:

chmod +x 3cxstatuscheck.pl

Edit using nano:

#!/usr/bin/perl
#
#
#Script which checks several things on a linux box and then reports back to PRTG
#
$message = "3CX DNS resolve services and logfile OK ";
$status = "0";
@services = ("3CXAudioProvider01","3CXCfgServ01","3CXEventNotificationManager","3CXIVR01","3CXMediaServer","3CXPhoneSystem01","3CXPhoneSystemMC01","3CXQueueManager01","3CXSystemService01","3CXTunnel01");
# Get information from PING about DNS lookupability
open(DNS, "nslookup www.cisco.com|");
@dnsout = <DNS>;
close(DNS);
if ($dnsout[3] =~ m/can't find/)
{
$message = "Unable to resolve DNS";
$status = "1";
}
#check all of the services
foreach $service (@services)
{
open(SERVICECHK, "systemctl status $service|");
@servicestatus = <SERVICECHK>;
close(SERVICECHK);
# print "\n $servicestatus[2] \n";
if ($servicestatus[2] =~ m/running/)
{
#this service is active
}
else
{
#something is wrong with this service
$status = "1";
$message = "One or more 3CX services currently not running";
}
}
#check the end of the log file
open(LOGCHK, "tail -n 500 /var/lib/3cxpbx/Data/Logs/3CXMediaServer* |grep Error|");
@logstatus = <LOGCHK>;
close(LOGCHK);
if ($logstatus[3] =~ m/Error/)
{
#something is wrong with this service
$status = "1";
$message = "3CX Logfile contains many recent errors";
}
if ($status eq '0')
{
print "0:0:3CX OK: $message";
}
else
{
print "2:2:3CX DEGRADED: $message";
}

Add to PRTG as an SSH script sensor.

Install 3CX SBC on Raspberry Pi

This guide is broken into two sections. The first section covers the installation & configuration of the Raspberry Pi’s OS,
and the second section covers the installation & configuration of the 3CX-SBC program that will be running on the Pi.

Section 1: Installation & Configuration of Raspbian Linux on the Raspberry Pi:

Download latest Raspbian Linux Lite from raspberrypi.org – https://www.raspberrypi.org/downloads/
Use Etcher to write the downloaded Linux image to the SD card – https://www.balena.io/etcher/
Remove and re-insert the SD card
Use notepad or similar to create a blank text file on the root of the SD card called ssh and remove the extension from the filename
Unmount the SD card and insert into the Raspberry Pi
Connect to network & power
Locate the let it boot, locate it in DHCP (should appear as ‘raspberrypi’)
SSH to the Raspberry Pi using the IP address in DHCP with username: pi, and password: raspberry
Enter in sudo raspi-config
Using the Raspberry Pi configuration utility, make the following adjustments:
Under the localisation menu, set up appropriate settings for the region in all four sub menus:

  • Change Locale to en_AU.UTF-8
  • Change Timezone to Australia, Melbourne
  • Change Keyboard Layout to EN_AU
  • Change Wi-Fi Country to Australia
  • Back out to the main menu, and enter the Network Options

Change hostname to something meaningful like 3CXSBC01
Change the user password for the account ‘pi’ to something else
Identify the MAC address either in DHCP or using the ‘ifcommand’ & looking at the ether line under eth0
Log into the client’s DHCP server and create a DHCP reservation for the MAC address on their network (assuming the VLAN for VoIP has already been setup) – a static IP address can also be used instead of a reservation.
Update the client docuemntation with the hostname, IP address, username & password
Reboot the Pi after exiting the configuration program
SSH back into the pi
Enter the command: sudo apt-get update to install any updates to the OS

Section 2: Installation & Configuration of 3CX-SBC onto the Raspberry Pi:

Now it’s time to download and install the 3CX-SBC program onto the Pi…
Enter the command:

wget https://downloads-global.3cx.com/downloads/sbc/3cxsbc.zip -O- | sudo bash

You will be presented with the 3CX SBC installer program which will outline the 3CX system requirements for the version of SBC you are installing on the Pi.
Press OK, accept the license agreement (no one is going to read this anyway)
From here, you will need to enter in the URL from the 3CX web interface for the SBC Trunk
Next enter in the Authentication key
Press OK to proceed and it will finalise configuration
Confirm in the 3CX Web console that the SBC trunk has come online

Congratulations! You have successfully completed the instalation of 3CX-SBC on a Raspberry Pi

Useful Xsan administrative commands for Mac OS X MDC’s

  • cvadmin – Administer an Xsan File System (show volumes, stop volumes, start volumes, view storage pools, manage quotas
  • cvaffinity – List or set affinities for storage pools
  • cvcp – Xsan copy utility (use at your own risk)
  • cvdb – Xsan debugger
  • cvdbset – Used to control the Xsan debugger
  • [slider title=”cvfail”]cvfail[/slider]- Fail volumes over between metadata controllers
  • cvfsck – Check consistency and repair Xsan volumes
  • cvfsdb – FileSystem debugging tool
  • cvfsid – Display system identification information (useful when integrating StorNext clients)
  • cvgather – Compile debugging information for Xsan
  • cvlabel – Label LUNs for use with Xsan
  • cvmkdir – Directory creation tool for Xsan
  • cvmkfile – File creation tool for Xsan
  • cvmkfs – File system (volume) creation tool for Xsan
  • cvuntrespass – Recover files that trespass into restricted areas (like when you got caught jumpin’ the fence of that sorority house back in the day)
  • cvupdatefs – Make a change to an existing volume
  • cvversions – Obtain patch level and versioning information for the system, Xsan and when the patches were compiled.
  • fsm – Volume controller process
  • fsmpm – Volume manager that runs on each node
  • mount_acfs – Xsan mounter
  • sndiskmove – Migrate the contents of one LUN to another LUN
  • sndpscfg – Disk proxy server config tool
  • snfsdefrag – Defragment the volume
  • snmetadump – Save and/or process metadata
  • snmetatar – Backup metadata to tar
  • xsanctl – Xsan control tool allows you to quickly and easily ping (check a client), mount/unmount volumes and check that volumes and disks haven’t changed, all client-side
  • xsand – Xsan client daemon, reads the /Library/Filesystems/Xsan/config/automount.plist and mounts volumes as indicated in the property list

Notes and usage for the CVADMIN utility:

Of all the command line tools available to assist you in the management of an Xsan volume, cvadmin serves as the primary command line tool to interface with, troubleshoot, and ultimately administer your Xsan. It provides for capabilities beyond what is available through Apple-provided GUI tools, which can be extremely useful for resolving the more complex problems that can crop up. Given the reported issues with Xsan Admin occasionally misreporting information, cvadmin is one of the tools that can help to make your experience administering an Xsan much less frustrating.

Read more below…

The basics:
Located at /Library/Filesystems/Xsan/bin/cvadmin, this tool can be run either interactively or non-interactively with the ‘-e’ flag. For the purposes of this article, we’ll be using primarily the interactive function of cvadmin. In it’s most basic form, cvadmin is started with no arguments, but must run as root. If you fire up cvadmin from a different user account, the tool will run, but you will not be able to access your filesystems. To get started we’ll launch the program with elevated privileges:

fig. 1
$ sudo /Library/Filesystems/Xsan/bin/cvadmin
Xsan Administrator
Enter command(s)
For command help, enter "help" or "?".

List FSS

File System Services (* indicates service is in control of FS):
1>*MyVolume[0] located on 192.168.56.5:51520 (pid 512)
2> MyVolume[1] located on 192.168.56.6:51520 (pid 509)

Select FSM "MyVolume"

Created : Tue Jan 13 15:33:57 2009
Active Connections: 1
Fs Block Size : 16K
Msg Buffer Size : 4K
Disk Devices : 2
Stripe Groups : 2
Fs Blocks : 61277616 (935.02 GB)
Fs Blocks Free : 61006893 (930.89 GB) (99%)


Xsanadmin (MyVolume) >

When cvadmin is first invoked it displays all of the valid File System Services (which in this context means volumes per metadata controller) and selects our only volume. In this particular instance, you see that there are two entries for “MyVolume”. This is completely normal as you should see one entry per volume per metadata controller. In this case, we have one volume and 2 metadata controllers, so we have 2 entries. The asterisk denotes the active FSS (or active metadata controller), in this case 192.168.56.5.

In order to perform any worth while tasks using these tools, we next need to ‘select’ a volume. In this particular instance, there is only one volume and so cvadmin ‘selected’ the active volume and displayed the statistics for that volume. But in environments where there are multiple volumes you will need to ‘select’ a volume before you proceed with using cvadmin. The cvadmin prompt will always display the active volume (in this case ‘MyVolume’), so there is no confusion as to which is being administered:

Xsanadmin (MyVolume) >

If more than one volume existed, we may desire to operate on a different volume, to do so we can simply run the command “>select volumeName” which would then select the volume “volumeName” and output statistics for it. Alternatively, the select command can be run with no arguments to output a list of all availableFile System Services.

fig 2.
Xsanadmin (MyVolume) > select
List FSS

File System Services (* indicates service is in control of FS):
1>*MyVolume[0] located on 192.168.56.5:51520 (pid 512)
2> MyVolume[1] located on 192.168.56.6:51520 (pid 509)

Practical Administration:
Ok, so we now know how to run the tool and select a particular volume, but what else can we do with it? Well, the answer is “quite a bit”; for the most part, my day-to-day Xsan administration happens only in cvadmin, the only reason that I typically fire up Xsan Admin is to help end users who rely on it. A full list of commands is available in the cvadmin man pages, or by typing “help” in an interactive cvadmin session. That being said, the commands listed below are my most frequently used:

>who

Query client list for the active file system. The output will show the following information for each client.SNFS I.D. – Client identifier Type – Type of connection. The client types are: FSM – File System Manager(FSM) process ADM – Administrative(cvadmin) connection CLI – File system client connection. May be followed by a CLI type character: S – Disk Proxy Server C – Disk Proxy Client H – Disk Proxy Hybrid Client. This is a client that has been configured as a proxy client but is operating as a SAN client. Location – The clients hostname or IP address Up Time – The time since the client connection was initiated License Expires – The date that the current client license will expire

>stats

Prints out volume statistics.

>stop/start MyVolume
>stop/start MyVolume on 192.168.5.5

The stop and start commands are equivalent to starting or stopping the volume in Xsan. However, by specifying a hostname/ip, we can stop file system services only on that particular MDC, which can be handy for maintenance purposes.

>fail MyVolume

This will failover the volume “MyVolume” and initiate a FSS vote amongst your metadata controllers. The metadata controller providing services for this volume with the highest failover priority should win this election. If no failover is available, the volume will failback to the original host that was hosting the volume.

>fsmlist

This will output a list of FSM processes on the machine that is selected, which is useful when determining which volumes it is capable of hosting as a metadata controller.

>repof

This will generate an open file report to /Library/Filesystems/Xsan/data/MyVolume/open_file_report.txt. This report includes a slew of information, but noticeably absent is the actual file name. Arg! It does offer an inode number for the file in question though, so you can use a command such as `find /Volumes/MyVolume -inum X` to determine the actual file from the published inode number. The >repof command can be very useful when attempting to determine why a client will not unmount a volume.

Troubleshooting:
There are also a number of options to help with more complex troubleshooting.

>show
>show long

This will output information about the stripe groups/storage pools used by this volume. It is useful for cross referencing index numbers outputted in system.log to human readable storage pool names. It also provides various statistics and configuration, such as stripe group role, corresponding LUNs, affinity tags, multipath method, and other useful bits of information.

>paths

This will output a list of LUNs visible to the node and the corresponding HBA port used to communicate with that LUN. This option can be helpful when you are getting those pesky “stripe group not found” errors.

>debug 0x01000000

This will output IO latency numbers to /Library/Filesystems/Xsan/data/MyVolume/log/cvlog immediately (which is otherwise done every hour). The key figure to look at in this output is the “sysavg” number for “PIO HiPriWr SUMMARY”. If your metadata is hosted on an Xserve RAID volume, this number should be below 500ms. If you’re using Promise based storage, the active/active controller setup introduces additional latency, you will see numbers in the 805-1000ms range.

>latency-test

Use this command to run latency tests between the FSM and clients. It can be used to isolate problematic clients on the SAN.

>activate MyVolume 192.168.56.5

Use this command to activate FSS services for the specified IP/hostname. Alternatively you can leave off the IP and it will activate the local server (if applicable). This command can be run on an MDC if it is not showing appropriate FSS services available. If you see errors to the effect that an MDC is on ‘standby’, activating the volume on the respective server will often address this issue.

When to Use Another Tool:
The cvadmin tool is very useful when troubleshooting metadata controller behavior. But cvadmin isn’t used when you want to perform Xsan setup or client management operations. To label LUNs you would use cvlabel. To mount and unmount volumes you would likely use the new xsanctl tool or ‘mount -t acfs’. To perform defrag operations and volume maintenance you would use the snfsdefrag and cvfsck tools, respectively. While you can add serial numbers and create volumes from the command line, it is probably much easier to continue performing these operations through the Xsan Admin GUI tool.

All in all, cvadmin can be a very useful tool. It is fast and can help to ease the administrative burden of managing an Xsan once you get used to it. Unlike the GUI, the information that it displays can always be trusted to be an accurate representation of the state of your SAN. It can also provide more insight when you’re troubleshooting and help you to become a more lucid Xsan administrator.

Archive and restore Open Directory data

You archive and restore Open Directory data using the Server app or the command line. To archive or restore a copy of your Open Directory data using the command line, use the slapconfig command. You can archive a copy of the data while the Open Directory master is in service.

The following files are archived:

  • The LDAP directory database (includes password data) and configuration files
  • Kerberos configuration files
  • Keychain data needed by Open Directory

Archives are only used by Open Directory masters. If a replica develops a problem, you can remove it as a replica from the Open Directory master, set up the replica as if it were a new server (with a new host name), then set it up again as a replica of the same master.Important: Carefully safeguard the archive media that contains a copy of the Open Directory password database, the Kerberos database, and the Kerberos keytab file. The archive contains sensitive information. Your security precautions for the archive media should be as stringent as for the Open Directory master server.

If you enable Time Machine on the server, directory and authentication data is automatically archived.

Archive Open Directory data using the Server app

  1. In the Open Directory pane, click Servers.
  2. Choose Archive Open Directory Master from the Action pop-up menu (looks like a gear).
  3. In the Archive File field, enter or choose the path to the folder where you want the Open Directory data archived.
  4. Enter a password for the archive, then click Next.
  5. Confirm your settings, then click Archive.

Archive Open Directory data using the command line

You can archive Open Directory data from the command line.

To archive Open Directory data, open the Terminal app (located in the Other folder in Launchpad), then enter the following command:

$ sudo slapconfig -backupdb /full/path/to/archive For example, /full/path/to/archive could be /Volumes/Data/myODArchive.

Enter a password to encrypt the disk image. Encrypting the image protects the sensitive data in the Open Directory database.

The archive file will have the file extension “.sparseimage”.

Restore Open Directory data using the Server app

  1. In the Open Directory pane, turn Open Directory on.
  2. Select “Restore Open Directory domain from an archive,” then click Next.
  3. In the Archive File field, enter or choose the path to the Open Directory archive file.
  4. Enter the password for the archive, then click Next.
  5. Click Restore.

Restore Open Directory data using the command line

You can restore Open Directory data from the command line.

To restore Open Directory data, open the Terminal app (located in the Other folder in Launchpad), then enter the following command:

sudo slapconfig -restoredb /full/path/to/archive.sparseimage

For example, /full/path/to/archive.sparseimage could be /Volumes/Data/myODArchive.sparseimage.If you entered a password to encrypt the data when you archived it, enter that password when prompted.

The “Strict-Transport-Security” HTTP header is not set to at least “15552000”

The “Strict-Transport-Security” HTTP header is not set to at least “15552000” seconds. For enhanced security, it is recommended to enable HSTS

Edit your Apache vHost file configuration for NextCloud. If you have two (one for port 80, the other for port 443), then edit both

Right under the first block that contains the ServerAdmin, DocumentRoot, ServerName, and ServerAlias details, add another line with the below:

Header always set Strict-Transport-Security “max-age=63072000; includeSubDomains”

Save and close the configuration files

Restart the Apache web server

sudo systemctl restart apache2

Refresh the settings page in NextCloud and that alert message should now be removed.

3CX v16 Not Updating

This document applies to 3CX v16 instances hosted in AWS or running on Debian 9 (Stretch) that are stuck on older versions of 3CX v16 and seemingly just will not update.

SSH or web-console into the Debian instance

Edit the file /etc/apt/sources.list.d/saltstack.list

sudo nano /etc/apt/sources.list.d/saltstack.list

If the one line in this file reads: deb http://repo.saltstack.com/apt/debian/9/amd64/archive/2019.2.0/ stretch main
Then add # in front of it and add an extra line below that reads: deb http://repo.saltstack.com/apt/debian/9/amd64/latest stretch main

Your file should now read:

#deb http://repo.saltstack.com/apt/debian/9/amd64/archive/2019.2.0/ stretch main
deb http://repo.saltstack.com/apt/debian/9/amd64/latest stretch main


Save and close the file
CTRL+O
CTRL+X

Now manually update and upgrade the packages:

sudo apt-get update
sudo apt-get upgrade

Answer Y when prompted to proceed
If prompted about updating the configuration of the Minion package, say Y and press enter

Once the upgrades are completed, you can now go through the 3CX web console and start installing all the pending updates – note, there will be quite a few.

Note: Changes as of December 2021:

I had to update a 3CX instance tonight that refused to update using the 3CX console or the above.

In the end, I had to edit the file:

/etc/apt/sources.list.d/saltstack.list

and enter in the line:

deb https://repo.saltproject.io/py3/debian/9/amd64/latest/ stretch main

Next, you’ll need to install APT’s secure transport module using:

sudo apt-get install apt-transport-https

Now do the update:

sudo apt-get update
sudo apt-get upgrade

Now head back the 3CX Admin Console and continue upgrades from there…