Inside a running ViciBox lab: the VICIdial filesystem map

Why this map matters

The previous lesson toured the lab's running processes. This one tours the same lab through its files: where the software lives, where it writes evidence of what it did, and which configuration values are safe to look at in a shared terminal.

Knowing this map in advance means that when you eventually need to investigate a real problem, you already know where to look — and, just as importantly, where not to look without a specific reason. A filesystem map is also quieter than a process tour: nothing here changes because you looked at it, so it is a safe way to get oriented on any VICIdial host, including one you did not build yourself.

The five stops in this tour are ordered from least to most sensitive: the software itself, then its logs, then a slice of its configuration, then recordings, then the web root. Notice how the caution in the guidance grows as the tour proceeds — that ordering is deliberate, not incidental.

None of the five stops requires anything beyond ordinary read access. If any command here reports a permission error where this lesson expects success, that itself is useful evidence — it means the account you are using has narrower access than a typical administrator account on this host, worth understanding before you continue.

• Where the dialer software itself lives, separate from its logs
• Which configuration keys are safe to read in a shared terminal, and which are not
• Where completed call recordings land, and why this tour never lists their filenames

Where the Perl scripts live

astguiclient's daemons — the same processes the previous lesson found running inside detached screen sessions — are Perl scripts installed under one shared directory. Listing that directory shows you the software itself, not any data it produced.

ls -la /usr/share/astguiclient | head -20

Where each process writes its own log

Each astguiclient daemon keeps a log of what it has been doing, separate from Asterisk's own logs and separate from the system journal. That separation matters: Asterisk's logs describe call signaling and media, while astguiclient's logs describe dialer-control decisions such as pacing adjustments — the same symptom can show up in one log and not the other, depending on which layer is actually responsible.

• Whether a log file's timestamp is recent, given how long the lab has been running
• Which daemon a given log filename corresponds to, from the previous lesson's process tour

ls -la /var/log/astguiclient | head -20

Read the non-secret half of astguiclient.conf

`/etc/astguiclient.conf` holds both operational settings and the database credentials astguiclient itself uses to connect. It stores every setting as a plain key=value pair, one per line — no section headers, no quoting, just a key, an equals sign, and a value. Grep for the specific keys you need instead of opening the whole file, and never grep for the credential keys in a shared terminal or paste them into a ticket.

A word-boundary grep such as the one below matters here for a small but real reason: without it, a pattern like `VARDB_server` would also match a longer key that happens to start the same way. Anchoring the pattern to the start of the line and a word boundary keeps the match limited to exactly the keys you intended.

• The database server address key, without ever printing the credential keys alongside it
• The database name, to compare against what the read-only-database-account lesson has you configure
• The configured port, in case your build does not use the default

grep -E '^(VARDB_server|VARDB_database|VARDB_port)\b' /etc/astguiclient.conf

Look at the completed-recordings folder without listing its files

Finished call recordings land under `/var/spool/asterisk/monitorDONE`, organized into subdirectories — but not one per day or per campaign. On this build the subdirectories are format and transfer stages that VICIdial's own audio-processing scripts move a recording through: FTP, FTP2, GPG, GSM, GSW, MP3, OGG and ORIG. A cron job compresses finished recordings to MP3 on a schedule, which is part of why a recording's exact location can shift over time even though the recording itself never moves anywhere outside this tree. This is the one place on the host where you should look but never list in full.

The distinction this section teaches is between confirming a folder exists and reading what is inside it. The `-d` flag on `ls` is what makes that distinction possible: it asks for information about a directory itself — its own ownership, permissions and name — rather than the directory's contents, which is what a plain `ls` without `-d` would print instead.

ls -ld /var/spool/asterisk/monitorDONE /var/spool/asterisk/monitorDONE/*/

Find the web root

VICIdial's Admin and Agent screens are PHP scripts served from one directory on ViciBox. Knowing where that directory is matters later, when a lesson talks about the Call URL feature, a custom script placed alongside the application, or simply where a certificate or virtual-host configuration expects the application's files to live.

This path is specific to how ViciBox lays out its own installation; a from-scratch install on a different distribution can and often does choose a different location for the same files, which is one more reason this curriculum treats ViciBox's own paths as this build's values rather than a universal VICIdial convention.

ls -ld /srv/www/htdocs

Ready for the next lesson

You have now toured this lab from both its processes and its filesystem. Continue to the VICIdial terminology lesson before opening the Admin screen and creating anything — the two tours together give you a mental map of the host, and the terminology lesson gives you the words for what that map's software actually does once you start configuring it.

Keep the database name you read from astguiclient.conf in this lesson. The read-only-database-account lesson two stops back asked you to record the same value, and the admin-pathway lesson shortly after this one will ask you to query the database by name for the first time.