Play MIDI files from Terminal
Requirements: Brew (Homebrew) to be installed & configured
Terminal commands:
$ brew install timidity $ timidity file.midi
About Month: July 2021
Play MIDI files from Terminal
Requirements: Brew (Homebrew) to be installed & configured
Terminal commands:
$ brew install timidity $ timidity file.midi
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 .
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.
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.
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.
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
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.
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.
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 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
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.
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:
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.
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”.
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.
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.
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.
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…