Reader setup
Before you apply
- A completed ViciBox Express lab, powered on and reachable
- Root or sudo access on that lab host to read the paths in this lesson
- Agreement not to list or paste filenames from the completed-recordings folder
- Expected result
- You can locate astguiclient's scripts and logs, read the non-secret half of its configuration file, and confirm the recordings folder and web root exist without exposing a customer's phone number.
- Before making changes
- Filenames under monitorDONE can encode a real phone number or lead ID. This lesson lists directories only, and so should every lesson after it.
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.
- Before you use it
- Run this on the lab host. Listing a directory changes nothing on disk.
ls -la /usr/share/astguiclient | head -20Captured demo response · 2026-09-23 21:35 UTC. Any filtering, hidden values or test-only data are identified in the capture label. Select Replay transcript to read the recorded output.
- Success looks like
- You see a list of `.pl` files and supporting scripts, each one a component of the dialer-control system the previous lesson's screen sessions were running.
- Stop if
- If the directory is missing, verify the host and installation path with the administrator before concluding the installation is incomplete.
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.
- Before you use it
- Run this on the lab host. This lists filenames and sizes only; it does not open or print any log's contents.
ls -la /var/log/astguiclient | head -20Captured demo response · 2026-09-23 21:35 UTC. Any filtering, hidden values or test-only data are identified in the capture label. Select Replay transcript to read the recorded output.
- Success looks like
- You see one or more log files, generally named after the daemon that writes them, with recent modification times if the lab has been running.
- Stop if
- Log files with very old timestamps on a lab you believe is active suggest the corresponding daemon stopped writing — cross-check against the process tour's screen-session count before concluding anything is broken.
- 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
Read the non-secret half of astguiclient.conf
The configuration file includes both operational settings and database credentials. Syntax varies by installation: the inspected current lab uses key => value, while older captures can differ. Inspect only approved non-secret keys and avoid printing credentials; do not assume a single separator across builds.
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.
- Before you use it
- Run this on the lab host. This grep deliberately excludes VARDB_user and VARDB_pass — those two hold astguiclient's own database login, and the read-only-database-account lesson earlier in this stage explains why you should never capture or paste them, even into a private note.
grep -E '^(VARDB_server|VARDB_database|VARDB_port)\b' /etc/astguiclient.confCaptured demo response · 2026-09-23 21:35 UTC. Any filtering, hidden values or test-only data are identified in the capture label. Select Replay transcript to read the recorded output.
- Success looks like
- Each matching line prints in key=value form, for example `VARDB_database=<your database's name>`; record the database name for later SQL lessons, but do not paste the whole file.
- Stop if
- If none of the three keys appear, confirm you are reading the file on the ViciBox lab host and not a copy or a different server — the key names themselves are stable across VICIdial installs.
- 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
Look at the completed-recordings folder without listing its files
On the documented lab, completed recordings use `/var/spool/asterisk/monitorDONE` and its subdirectories; layouts can differ by build. 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, so a recording’s location can change as it is processed or transferred. 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.
- Before you use it
- Run exactly this command, with the -d flag, on the lab host. -d prints information about each directory itself rather than listing what is inside it.
ls -ld /var/spool/asterisk/monitorDONE /var/spool/asterisk/monitorDONE/*/Captured demo response · 2026-09-23 21:35 UTC. Any filtering, hidden values or test-only data are identified in the capture label. Select Replay transcript to read the recorded output.
- Success looks like
- You see metadata for the top-level folder and any matching subdirectories. Their existence does not prove the recording pipeline is writing. Directory names can also be sensitive; do not share the output without review.
- Stop if
- Do not follow this command with a plain `ls` or `find` on the same path. Filenames inside monitorDONE routinely encode phone numbers and lead IDs, so never list, paste, or screenshot them outside an approved, authorized audience.
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.
- Before you use it
- Run this on the lab host. This reads one directory's metadata and changes nothing.
ls -ld /srv/www/htdocsCaptured demo response · 2026-09-23 21:35 UTC. Any filtering, hidden values or test-only data are identified in the capture label. Select Replay transcript to read the recorded output.
- Success looks like
- The listing shows the directory’s owner and permissions. Compare the path with the web server’s configuration; directory ownership alone does not prove what the server serves.
- Stop if
- If the path does not exist, confirm you are on the ViciBox host and not a generic Linux install — a stock ViciBox appliance creates this path as part of its own installation.
Recorded lab terminal: web root
Open to enlarge
Capture details
Read-only observation, not a completed call or routing test. Display trims blank space; enlargement opens the complete original. Removed local SSH client post-quantum negotiation warning from stderr; command stdout preserved.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.
Checks and sources
What was checked
- Every sample lists a directory's metadata or greps a named, non-secret configuration key; none of them opens a recording, a lead export, or a credential.
- Reviewed read-only SSH observations were added from the ViciBox 12 / SVN 4037 demo on November 4, 2026. Captures show point-in-time state, not successful calling, routing, audio, API writes or recovery.