Packages with apt

02Privilege and sources are part of setup

apt update refreshes the locally stored information about configured repositories. apt install requests named packages and any needed dependencies. If the named package is already installed, install may update it. apt upgrade requests eligible upgrades for installed packages. These actions have different effects.

apt-cache policy curl displays information such as an installed version, a candidate version and its source. Candidate means the version the package system currently selects for a possible installation. Seeing it in policy output does not show that it was installed.

System package changes normally require the guest's applicable administrator policy, so elevated examples use sudo. Sources must also be approved and trusted. Repository signatures help establish package authenticity; do not disable their checks or add an unknown repository to make a command available.

Before accepting an install, review the proposed additions, removals, updates, download size and disk needs. The -y option would accept ordinary confirmation prompts automatically; this activity does not use it. If policy, space or network conditions are unsuitable, stop and use the printed card.

sudo apt update

metadata refresh requested in this model

installed version unknown; no install/upgrade requested

installed / candidate / source: not observed

03Try a package record

The required activity reads a fictional package decision card. It supplies a refresh and candidate information while leaving installation as a separate decision. No real package version or successful network operation is invented in that card.

For a fresh paper comparison, imagine an approved named installation changes a program from version A to version B. Identify the before/after installed-version evidence that supports that claim. Compare it with the worksheet's information-only refresh. The optional guest steps below let you record your own actual observations if permitted; they are unnecessary for the paper reasoning.

Separate package information from installation

A repository supplies packages and metadata describing them. Refreshing
metadata changes local information. An installation transaction can
change installed software and its dependencies. A candidate is the
version currently selected for possible installation, not proof that
installation occurred. Read the fictional decision below.

The decision card is fictional, not actual apt output.
Worked decision: update fetches repository metadata; policy displays
available/installed information; install requests named package(s).
Activity record: approved Ubuntu repository set; metadata refresh
completed; fictional curl upgrade candidate exists; no install or
upgrade requested. Does that alone establish installed curl changed?
No versions, package sizes or successful real transactions are claimed.
Live candidate steps inside owned guest only:
apt-cache policy curl
sudo apt update
apt-cache policy curl
sudo apt install curl  (optional; review transaction before accepting)
curl --version        (only if curl is installed)
Never add a third-party repository, pipe a download to a shell or use -y.
Question: apt update completed; was every available upgrade installed?

Record what the package evidence actually shows

Fill only the fields you observed. For a paper activity, mark results
as predictions and leave installed versions unknown. Keep the requested
action separate from the resulting state. Do not record passwords or
private keys.

Host/guest OS release and architecture:
Bash/coreutils/findutils/grep/tar/procps/man/nano/SSH versions used:
Locale/encoding: candidate LC_ALL=C; UTF-8 fixture bytes
Approved repositories / package policy source:
Chosen package / installed version before / candidate / version after:
Actual transaction requested / accepted / deferred:
Expected result vs observed stdout, stderr and status:
Working directory / scope / cleanup or retained files:
Do not put passwords, private keys or personal identifiers in this record.

1. Read the card: metadata refreshed, no install/upgrade requested. Predict whether that establishes changed installed curl. Expected: it does not; metadata and installed files are different state.
2. If doing the optional live route, inspect apt-cache policy curl first and record actual installed/candidate/source information. Confirm the configured approved repository set and guest scope before any elevated action.
3. If allowed, run sudo apt update inside the guest and inspect policy again. Record success/failure as observed; don't continue installation after a failed or untrusted-source refresh. Use the guest password privately if policy requests it.
4. Only if a needed curl installation is approved, review sudo apt install curl and accept only the stated guest transaction. Cancel on unexpected changes. Record curl --version after successful installation, or mark install/version observation deferred. No external URL needs to be fetched.
5. Keep the package record. Do not remove dependencies or run autoremove as an exercise cleanup. Retain the approved tool for later lessons, or restore a known guest baseline only when all later guest work is disposable.

04Finding and processing module case

The search-process-case card gives every line of queue.txt and a fictional job/package record. Its optional archive contains those ordinary files. List entries first and use a new processing-review destination if extracting.

Choose a content search to select READY, then save only that line into a new result.txt. With grep -n, the predicted selected line is 3:status=READY. The line number refers to queue.txt, not to the filtered result file.

Check your note: separate name search from content search, trace stdout to the output file, and distinguish refreshed package information from installation. Job 2 and PID 880 are fictional identities for reasoning; never use them as live targets. State whether your evidence was observed or predicted.

YanoSec / Finding and processing module case
Original fictional evidence.
search-process-case/notes/queue.txt:
  task=desk
  status=WAIT
  status=READY
Job card: own sleep job 2, PID 880; unrelated PID 881 must not be signaled.
Package card: metadata refreshed; no install/upgrade transaction requested.
Choose filename vs content search; predict READY line output saved to
a fresh file; identify only the owned job; explain package-state limit.
PID/job numbers are paper fixtures, never live command targets.

Read an owned archive before extracting it

An archive bundles named entries. Extracting writes those entries back
to disk. A .tar.gz file uses tar bundling plus gzip compression; neither
operation encrypts the content. Use only the supplied owned archives.

All supplied archives contain original ordinary text files under one
named directory. No symlinks, executables with special modes, devices,
absolute paths or parent traversal entries are authored. Inspect first.
Save the chosen archive in the GUEST Downloads folder. If its actual
location differs, use that quoted absolute path; do not guess.
Use a new destination beneath ~/yanosec-lab, never an existing folder.
Example templates (replace ARCHIVE.tar.gz and NEW-DEST):
tar -tzf ~/Downloads/ARCHIVE.tar.gz
mkdir ~/yanosec-lab/NEW-DEST
tar -xzf ~/Downloads/ARCHIVE.tar.gz -C ~/yanosec-lab/NEW-DEST
Run the extraction only if mkdir succeeded and inventory matches.
t lists; x extracts; z handles gzip; f names archive; -C names target.
Keep original data; do not use sudo, overwrite flags or root extraction.
Stop on an unexpected path/link/member or download you cannot identify.
Fallback: read the full inline tree and contents; predict actions in notes.
Cleanup: leave scoped files for review; restore a guest baseline only
if all subsequent guest work is disposable. No broad rm command.

05Optional challenge

Allow about ten extra minutes. An installed package has a newer candidate. Describe which installed, candidate and source information you would record before and after an approved installation. Explain why comparing two metadata-refresh messages would not establish the installed version changed.

06Fresh cases for the checks

Use these fictional cases for the checks below. They have different inputs from the worked examples. Read them here or make notes; no installation or external service is needed.

Record U: apt update completed; local repository metadata refreshed.
          No install or upgrade transaction was requested.
Record I: apt install map-tool completed an approved named-package transaction.
          Before: map-tool absent. After: map-tool installed, version 2.4.
Record G: apt upgrade completed an approved eligible-upgrade transaction.
          Before: note-tool 1.6. After: note-tool 1.7.
Record D: package bytes downloaded to a cache; transaction not started.
          Before and after installed-version records are identical.
Each record is independent. None establishes what happened on your device.

Package: chart-tool
Installed: 3.1
Candidate: 3.6
Candidate source: Campus Ubuntu mirror
No install/upgrade transaction is recorded after this policy reading.
The source label is supplied; this card does not verify repository approval or trust.

Complete owned queue.txt contents:
task=review
status=HOLD
status=READY
Successful paper command: grep -n READY queue.txt > ready.txt
ready.txt starts empty; each source line ends with a newline.
Before job creation: terminal L has no jobs.
After sleep 40 &: terminal L has job 4, PID 4608, sleep 40, still running.
Package event afterward: apt update completes; no package transaction follows.

Before: route-tool Installed 5.2; Candidate 5.8.
First event: apt update completed.
Changed case adds a second event: approved apt install route-tool completed.
After the second event: Installed 5.8; Candidate 5.8.
Assume the configured sources and transaction are approved for this fictional case.

07Explain a package decision

Optional self-check: write a short before/after package note and identify what would justify proceeding with an approved installation.

Check your explanation: distinguish metadata refresh, downloaded bytes and installed software; record installed and candidate versions with their source; state approval and trust assumptions; review proposed changes and dependencies. Keep fictional records separate from observations of your own environment.