Q: UNIX/Linux administration: Which command is used to immediately flush filesystem buffers and force all pending writes to disk (i.e., write cached blocks to storage)?

Introduction / Context: Modern UNIX/Linux systems aggressively cache disk writes in memory to improve performance. At times, an administrator needs to force these buffered writes to be committed to persistent storage, for example before removing power or unmounting a filesystem. The classic utility for this task is the sync command. Given Data / Assumptions: You are working on a UNIX or Linux system with standard core utilities available. There are pending filesystem buffers (dirty pages) that have not yet been written to disk. You want a user-level command that requests the kernel to flush these buffers. Concept / Approach: The kernel defers writes to batch I/O. The sync command asks the kernel to write all dirty filesystem caches (metadata and data) to disk devices. It does not guarantee hardware cache flush on every device, but it ensures the OS-level buffers are issued to storage. Running sync multiple times is harmless and sometimes used out of caution. Step-by-Step Solution: Run: syncOptionally run it more than once: sync; syncIf unmounting, first sync, then umount the filesystem to minimize data loss risk.For removable media, run sync before eject to ensure all writes are complete. Verification / Alternative check: Use tools like mount or lsof to ensure no open files before unmount. Review system logs (e.g., dmesg) to see any I/O errors. Some filesystems expose statistics (e.g., /proc/meminfo Dirty pages) that decrease after sync completes. Why Other Options Are Wrong: save: Not a standard UNIX command for flushing buffers. edbuff: Not a valid core utility. flush: Not a portable command for this purpose. None of the above: Incorrect because sync is the correct command. Common Pitfalls: Assuming sync powers off disks; it only requests write-out. Believing sync fixes hardware cache policies; device write caches may still hold data unless the kernel issues barriers. Always pair sync with proper unmount/eject procedures. Final Answer: sync

Q: Linux history: Who created the Linux kernel (initiating its development in 1991 as a free, open-source project)?

Introduction / Context: Understanding the origins of Linux helps learners grasp the ethos of open-source software development. The Linux kernel, which powers countless servers, desktops, and embedded devices, began as a personal project that rapidly grew into a global collaborative effort. Given Data / Assumptions: The question asks for the individual who developed the Linux kernel. Timeframe: initial public announcement occurred in 1991. Linux refers specifically to the kernel, distinct from other GNU tools and userland components. Concept / Approach: Linus Torvalds, then a student at the University of Helsinki, released the early versions of the Linux kernel, encouraging collaboration. While Richard Stallman founded the Free Software Foundation and the GNU project (providing userland tools and licenses), the kernel itself was created by Torvalds. Distributions combine the Linux kernel with GNU tools and other software. Step-by-Step Solution: Identify key figures: Linus Torvalds (kernel), Richard Stallman (GNU/FSF), Bob Young (co-founded Red Hat), others unrelated.Map roles: Kernel creation → Linus Torvalds.Select the corresponding option. Verification / Alternative check: Check historical archives (e.g., the famous 1991 announcement and early kernel releases). The distinction between “Linux kernel” and “GNU/Linux distribution” confirms the answer. Why Other Options Are Wrong: Bob Young: Business leader, co-founder of Red Hat, not the kernel creator. Mark Eving: Not a recognized figure in Linux history. Richard Stallman: Led GNU/FSF; pivotal to free software but did not create the Linux kernel. None of the above: Incorrect because Linus Torvalds is right. Common Pitfalls: Confusing GNU (userland) with Linux (kernel). Using “Linux” to refer to the entire operating system stack; technically the kernel is Linux, while distributions bundle it with other components. Final Answer: Linus Torvalds

Q: Red Hat Linux basics: Which of the following is typically NOT a component of the default Red Hat Linux email system stack (MTA, MUA, LDA/filters)?

Introduction / Context: Traditional UNIX-like email systems are composed of multiple layers: an MTA (Mail Transfer Agent) to route mail, an MUA (Mail User Agent) for reading/composing, and an LDA or filter such as procmail for delivery rules. Red Hat Linux historically shipped with a sensible default stack, though specific MUAs could vary. Given Data / Assumptions: MTA (e.g., Sendmail or Postfix) is present by default for system mail. An MUA such as mailx (or mutt) is commonly available for local mail reading. procmail has historically been used for local delivery and filtering. Pine (a full-screen MUA) was not always installed by default in base installs. Concept / Approach: Distinguish core mail infrastructure components from optional user-facing clients. The default base install tends to include an MTA and basic MUA utilities. Pine, while popular historically, was not guaranteed in default Red Hat installation sets and often required separate package selection. Step-by-Step Solution: Identify core infrastructure: MTA + basic MUA + procmail → default components.Identify optional client: Pine → user-level full-screen client, not necessarily default.Choose the option that is “not typically part of the default stack.” Verification / Alternative check: Review historical Red Hat package groups: “Mail Server” installs MTA and related tools; Pine often resided in optional or user applications groups. Why Other Options Are Wrong: The MTA: fundamental for system mail routing. The MUA (mailx/mutt): basic local mail reading; often present. procmail: widely used local delivery/filters on Red Hat systems. None of the above: incorrect because Pine is the exception. Common Pitfalls: Equating “default” with “available on media.” Optional packages can be on the install media but not installed by default. Also, configurations change across releases. Final Answer: Pine

Q: UNIX network services: Regarding NIS on UNIX systems, which single option best captures what NIS is and what it does?

Introduction / Context: NIS (Network Information Service), historically known as Yellow Pages (YP), is a long-standing UNIX facility for sharing administrative data such as user accounts and groups across multiple systems. Knowing what NIS is—and is not—helps in distinguishing it from unrelated desktop or GUI technologies. Given Data / Assumptions: NIS is a directory-like naming and lookup service for UNIX networks. It centralizes data like passwd, group, and other configuration maps. It is unrelated to graphical desktops or window managers. Concept / Approach: NIS provides centralized maps to simplify account management and authentication across a set of machines. It predates LDAP and modern directory services, but the conceptual role is similar: a shared source of truth for identity and configuration data. Documentation and command names (yp*) reflect its original “Yellow Pages” branding. Step-by-Step Solution: Assess statement A: Correct—NIS stands for Network Information Service and was formerly called Yellow Pages.Assess statement B: Correct—NIS centralizes passwd/group (and other maps) and enables network-wide authentication lookups.Assess statement C: Incorrect—NIS is not a GUI/window manager at all.Therefore, select “Both A and B are correct.” Verification / Alternative check: Cross-verify with admin manuals: ypbind, ypcat, and ypwhich are standard NIS utilities; none relate to X Window managers. NIS maps include passwd.byname, group.byname, etc. Why Other Options Are Wrong: A only / B only: Incomplete because both are true. C: Mischaracterizes NIS entirely. None of the above: False because A and B are accurate. Common Pitfalls: Confusing NIS with LDAP/Active Directory; assuming NIS provides encryption or strong security by default (it does not). Modern deployments may favor LDAP/Kerberos for stronger security and scalability. Final Answer: Both A and B are correct.

Question 1

Apache HTTP Server configuration  Identify the primary Apache configuration file on most Linux/UNIX installations (the central file that includes other conf.d or sites-enabled snippets).

Accepted Answer

Introduction / Context: Administering Apache requires familiarity with its main configuration file. On most distributions, Apache reads a primary file that defines global settings and includes additional configuration fragments. Recognizing this entry point simplifies enabling modules, virtual hosts, and performance tuning. Given Data / Assumptions: Standard Apache HTTP Server (httpd) deployment. Default main configuration file name is requested. Distribution-specific paths or include directories may vary, but the filename is consistent. Concept / Approach: The main configuration file is typically named httpd.conf. On some distros it lives under /etc/httpd/conf/httpd.conf (RHEL-based) or /etc/apache2/apache2.conf with includes to sites-enabled (Debian-based). However, the canonical filename referenced in documentation remains httpd.conf, and many systems link to or include it. Step-by-Step Solution: Identify the canonical Apache config filename: httpd.conf.Exclude unrelated system files or Windows-specific files.Acknowledge includes may supplement httpd.conf but do not replace its role.Select httpd.conf as the best answer. Verification / Alternative check: Run httpd -V or apachectl -V to reveal SERVER_CONFIG_FILE path. Inspect that file to confirm its role as the main configuration entry point. Why Other Options Are Wrong: apache.con is not a valid standard filename./etc/profile configures shell environments, not Apache.system.ini is a Windows-era INI file, not used by Apache on Linux/UNIX. Common Pitfalls: Editing a vhost include without adjusting main httpd.conf includes or module loads. Confusing Debian's apache2.conf layout with the concept of a “main file.” Forgetting to reload or gracefully restart the service after changes. Final Answer: httpd.conf

Question 2

RPM package building  When working with RPM source packages (SRPM), which rpm option rebuilds the package to include new patches and produce fresh binary RPMs?

Accepted Answer

Introduction / Context: RPM-based distributions (such as Red Hat and SUSE families) allow rebuilding binary packages from source RPMs (SRPMs). When you modify spec files or apply patches, you need the correct rpm command to rebuild clean binaries that incorporate those changes. Given Data / Assumptions: You possess an SRPM and have applied or referenced patches in the .spec file. You want the tool to perform the standard build sequence and output binary RPMs. Classic rpm build workflow is in use (alternatively rpmbuild on newer systems). Concept / Approach: Historically, rpm --rebuild SRPM_name runs prep, build, and packaging steps, emitting binary RPMs in the designated RPMS directory. Newer systems use rpmbuild --rebuild, but the concept and option remain the same: “rebuild” integrates your patches into the compiled output. Step-by-Step Solution: Place SRPM and patches where rpmbuild can access them.Invoke the rebuild operation, e.g., rpmbuild --rebuild package.src.rpm.Wait for compile and packaging; binaries appear under RPMS/.Install with rpm -Uvh newpackage.rpm after testing. Verification / Alternative check: Confirm that your patched content is present by using rpm -qlp on the resulting RPM or inspecting file versions and changelogs after installation. Why Other Options Are Wrong: --recompile historically compiles but may not complete full packaging pipeline.--generate and --execute are not standard rpm build options for SRPM rebuilding. Common Pitfalls: Forgetting to increment Release in the spec file after changes. Missing BuildRequires leading to failed compiles. Building as root instead of using an unprivileged user rpmbuild tree. Final Answer: - - rebuild

Question 3

Filesystem mounting configuration  On Linux, which configuration file lists filesystems and mount points so they can be mounted automatically at boot or on-demand with mount -a?

Accepted Answer

Introduction / Context: Persistent mounts in Linux are defined centrally so that disks, partitions, and network filesystems are mounted consistently at boot. Understanding the right file to edit is crucial for servers and workstations to ensure reliable storage access. Given Data / Assumptions: The system uses standard Linux tooling. We want the file that enumerates device-to-mount-point mappings with options. We plan to mount at boot and via mount -a. Concept / Approach: /etc/fstab (filesystem table) is the canonical configuration listing device identifiers (UUIDs or block paths), mount points, filesystem types, mount options, and fsck order. Contents are read by system startup scripts and by mount -a to mount all configured entries that are not marked noauto. Step-by-Step Solution: Open /etc/fstab as root to define persistent mounts.Use UUID= or LABEL= for stable device identification.Apply appropriate options (e.g., defaults, noatime, _netdev).Test with mount -a and verify with mount or findmnt. Verification / Alternative check: Run findmnt or cat /proc/mounts to confirm active mounts. System logs (journalctl) show boot-time mount success or failures tied to fstab entries. Why Other Options Are Wrong: /etc/mount.sys and /etc/filesys are not standard./etc/sysconfig stores various distro settings but not the master mount table. Common Pitfalls: Using device paths (/dev/sdX) that change; prefer UUID/LABEL. Forgetting noauto or _netdev on network mounts, causing boot delays. Incorrect fs_passno values that break fsck order on startup. Final Answer: /etc/fstab

Question 4

Linux system boot scripts  Which directory typically contains the core system boot scripts and initialization configuration (for example, init, init.d, rc*.d, or system-level service files)?

Accepted Answer

Introduction / Context: System initialization and service startup on UNIX/Linux are driven by configuration and scripts located in well-defined directories. Administrators often need to adjust service runlevels, enable/disable units, or modify default parameters at boot. Knowing the correct location simplifies these tasks. Given Data / Assumptions: Traditional SysV init placed scripts in /etc/init.d and symlinks in /etc/rc*.d. Modern systems using systemd still keep core configuration under /etc (e.g., /etc/systemd/system). We are asked for the directory that contains boot script configurations. Concept / Approach: /etc is the configuration hub. For SysV init, /etc/init.d and rc directories hold boot scripts. With systemd, unit overrides and local service files reside in /etc/systemd/system. Other directories serve different purposes and do not primarily store boot-time configuration scripts. Step-by-Step Solution: Recognize /etc as the home for system configuration.Identify init components (init.d, rc*.d) or systemd units under /etc hierarchy.Exclude directories unrelated to boot configuration.Select /etc. Verification / Alternative check: List /etc/init.d or /etc/systemd/system on a running system to observe service and boot files. Compare with /usr/lib/systemd/system for vendor defaults versus /etc for admin-defined overrides. Why Other Options Are Wrong: /dev contains device nodes./bin stores essential user binaries, not boot scripts./home contains user directories, not system boot configuration. Common Pitfalls: Editing files under /usr/lib/systemd/system instead of placing overrides in /etc/systemd/system. Deleting rc symlinks without understanding runlevels. Confusing boot scripts with kernel bootloader configs (which are under /boot). Final Answer: /etc

Question 5

OSI model fundamentals  Within the OSI networking model, which layer is responsible for routing packets between different networks?

Accepted Answer

Introduction / Context: The OSI model divides networking functions into seven layers, each with specific responsibilities. Routing—finding paths between networks—is central to internetworking and is performed by a specific layer that handles logical addressing and path selection. Given Data / Assumptions: OSI layers: Physical, Data Link, Network, Transport, Session, Presentation, Application. Routing entails moving packets across network boundaries using logical addresses. We must select the layer responsible for this function. Concept / Approach: The Network layer (Layer 3) provides logical addressing (e.g., IP), routing, and path determination. Routers operate at this layer, choosing next hops and applying policies such as metrics and access control lists. Other layers provide reliability, framing, or session control, but not routing across networks. Step-by-Step Solution: Identify routing as inter-network path selection.Map routing to Layer 3 functions: addressing, fragmentation, forwarding.Confirm devices: routers work at the Network layer.Select “network layer.” Verification / Alternative check: Consider examples: IP routing tables, OSPF, BGP—all are Layer 3 protocols and mechanisms, which validates the answer. Why Other Options Are Wrong: Session layer manages dialogues between endpoints; it does not route.Transport layer provides end-to-end reliability and flow control (e.g., TCP), not routing.Data Link layer handles local network framing and MAC addressing within the same broadcast domain. Common Pitfalls: Confusing switching (Layer 2) with routing (Layer 3). Assuming TCP ports (Layer 4) are used for routing; they are for multiplexing services. Mixing OSI terminology with TCP/IP model layers without mapping carefully. Final Answer: network layer

Question 6

Linux swap partitions with fdisk  When creating a dedicated swap partition using fdisk for Linux, which hexadecimal system ID type should you set for that partition so the kernel and tools recognize it as swap space?

Accepted Answer

Introduction / Context: On MBR-partitioned disks, fdisk assigns a one-byte hexadecimal “system ID” to each partition. Linux tools recognize certain IDs for filesystems and special purposes. Correctly tagging a partition as swap ensures the system can format and activate it during boot or on demand. Given Data / Assumptions: We are using classic MBR-style partitioning with fdisk. We want a dedicated Linux swap partition. We must choose the correct hex type value. Concept / Approach: By convention, 0x82 identifies a Linux swap partition, while 0x83 identifies a standard Linux filesystem partition (e.g., ext2/3/4, xfs when using MBR). Setting the correct ID helps initramfs and system tools like swapon/fstab recognize the partition's role. Step-by-Step Solution: Create the partition with fdisk.Set the type with the “t” command and enter 82 for Linux swap.Write changes, then run mkswap /dev/sdXN to format it.Add an entry in /etc/fstab using UUID=… with type swap and options like defaults. Verification / Alternative check: Use blkid to confirm type and UUID, then run swapon --show to verify activation. /proc/swaps lists active swap areas. Why Other Options Are Wrong: 83 corresponds to Linux filesystem partitions, not swap.5 is the old DOS extended partition type, not swap.4 is FAT16 <32M type in old DOS schemes, not swap. Common Pitfalls: Forgetting to run mkswap after setting the partition type. Not adding the swap entry to /etc/fstab for persistence. Using MBR types on GPT disks; with GPT, use partition type GUIDs and tools like parted. Final Answer: 82

Question 7

UNIX/Linux administration: Which command is used to immediately flush filesystem buffers and force all pending writes to disk (i.e., write cached blocks to storage)?

Accepted Answer

Introduction / Context: Modern UNIX/Linux systems aggressively cache disk writes in memory to improve performance. At times, an administrator needs to force these buffered writes to be committed to persistent storage, for example before removing power or unmounting a filesystem. The classic utility for this task is the sync command. Given Data / Assumptions: You are working on a UNIX or Linux system with standard core utilities available. There are pending filesystem buffers (dirty pages) that have not yet been written to disk. You want a user-level command that requests the kernel to flush these buffers. Concept / Approach: The kernel defers writes to batch I/O. The sync command asks the kernel to write all dirty filesystem caches (metadata and data) to disk devices. It does not guarantee hardware cache flush on every device, but it ensures the OS-level buffers are issued to storage. Running sync multiple times is harmless and sometimes used out of caution. Step-by-Step Solution: Run: syncOptionally run it more than once: sync; syncIf unmounting, first sync, then umount the filesystem to minimize data loss risk.For removable media, run sync before eject to ensure all writes are complete. Verification / Alternative check: Use tools like mount or lsof to ensure no open files before unmount. Review system logs (e.g., dmesg) to see any I/O errors. Some filesystems expose statistics (e.g., /proc/meminfo Dirty pages) that decrease after sync completes. Why Other Options Are Wrong: save: Not a standard UNIX command for flushing buffers. edbuff: Not a valid core utility. flush: Not a portable command for this purpose. None of the above: Incorrect because sync is the correct command. Common Pitfalls: Assuming sync powers off disks; it only requests write-out. Believing sync fixes hardware cache policies; device write caches may still hold data unless the kernel issues barriers. Always pair sync with proper unmount/eject procedures. Final Answer: sync

Question 8

Linux history: Who created the Linux kernel (initiating its development in 1991 as a free, open-source project)?

Accepted Answer

Introduction / Context: Understanding the origins of Linux helps learners grasp the ethos of open-source software development. The Linux kernel, which powers countless servers, desktops, and embedded devices, began as a personal project that rapidly grew into a global collaborative effort. Given Data / Assumptions: The question asks for the individual who developed the Linux kernel. Timeframe: initial public announcement occurred in 1991. Linux refers specifically to the kernel, distinct from other GNU tools and userland components. Concept / Approach: Linus Torvalds, then a student at the University of Helsinki, released the early versions of the Linux kernel, encouraging collaboration. While Richard Stallman founded the Free Software Foundation and the GNU project (providing userland tools and licenses), the kernel itself was created by Torvalds. Distributions combine the Linux kernel with GNU tools and other software. Step-by-Step Solution: Identify key figures: Linus Torvalds (kernel), Richard Stallman (GNU/FSF), Bob Young (co-founded Red Hat), others unrelated.Map roles: Kernel creation → Linus Torvalds.Select the corresponding option. Verification / Alternative check: Check historical archives (e.g., the famous 1991 announcement and early kernel releases). The distinction between “Linux kernel” and “GNU/Linux distribution” confirms the answer. Why Other Options Are Wrong: Bob Young: Business leader, co-founder of Red Hat, not the kernel creator. Mark Eving: Not a recognized figure in Linux history. Richard Stallman: Led GNU/FSF; pivotal to free software but did not create the Linux kernel. None of the above: Incorrect because Linus Torvalds is right. Common Pitfalls: Confusing GNU (userland) with Linux (kernel). Using “Linux” to refer to the entire operating system stack; technically the kernel is Linux, while distributions bundle it with other components. Final Answer: Linus Torvalds

Question 9

Red Hat Linux basics: Which of the following is typically NOT a component of the default Red Hat Linux email system stack (MTA, MUA, LDA/filters)?

Accepted Answer

Introduction / Context: Traditional UNIX-like email systems are composed of multiple layers: an MTA (Mail Transfer Agent) to route mail, an MUA (Mail User Agent) for reading/composing, and an LDA or filter such as procmail for delivery rules. Red Hat Linux historically shipped with a sensible default stack, though specific MUAs could vary. Given Data / Assumptions: MTA (e.g., Sendmail or Postfix) is present by default for system mail. An MUA such as mailx (or mutt) is commonly available for local mail reading. procmail has historically been used for local delivery and filtering. Pine (a full-screen MUA) was not always installed by default in base installs. Concept / Approach: Distinguish core mail infrastructure components from optional user-facing clients. The default base install tends to include an MTA and basic MUA utilities. Pine, while popular historically, was not guaranteed in default Red Hat installation sets and often required separate package selection. Step-by-Step Solution: Identify core infrastructure: MTA + basic MUA + procmail → default components.Identify optional client: Pine → user-level full-screen client, not necessarily default.Choose the option that is “not typically part of the default stack.” Verification / Alternative check: Review historical Red Hat package groups: “Mail Server” installs MTA and related tools; Pine often resided in optional or user applications groups. Why Other Options Are Wrong: The MTA: fundamental for system mail routing. The MUA (mailx/mutt): basic local mail reading; often present. procmail: widely used local delivery/filters on Red Hat systems. None of the above: incorrect because Pine is the exception. Common Pitfalls: Equating “default” with “available on media.” Optional packages can be on the install media but not installed by default. Also, configurations change across releases. Final Answer: Pine

Question 10

UNIX network services: Regarding NIS on UNIX systems, which single option best captures what NIS is and what it does?

Accepted Answer

Introduction / Context: NIS (Network Information Service), historically known as Yellow Pages (YP), is a long-standing UNIX facility for sharing administrative data such as user accounts and groups across multiple systems. Knowing what NIS is—and is not—helps in distinguishing it from unrelated desktop or GUI technologies. Given Data / Assumptions: NIS is a directory-like naming and lookup service for UNIX networks. It centralizes data like passwd, group, and other configuration maps. It is unrelated to graphical desktops or window managers. Concept / Approach: NIS provides centralized maps to simplify account management and authentication across a set of machines. It predates LDAP and modern directory services, but the conceptual role is similar: a shared source of truth for identity and configuration data. Documentation and command names (yp*) reflect its original “Yellow Pages” branding. Step-by-Step Solution: Assess statement A: Correct—NIS stands for Network Information Service and was formerly called Yellow Pages.Assess statement B: Correct—NIS centralizes passwd/group (and other maps) and enables network-wide authentication lookups.Assess statement C: Incorrect—NIS is not a GUI/window manager at all.Therefore, select “Both A and B are correct.” Verification / Alternative check: Cross-verify with admin manuals: ypbind, ypcat, and ypwhich are standard NIS utilities; none relate to X Window managers. NIS maps include passwd.byname, group.byname, etc. Why Other Options Are Wrong: A only / B only: Incomplete because both are true. C: Mischaracterizes NIS entirely. None of the above: False because A and B are accurate. Common Pitfalls: Confusing NIS with LDAP/Active Directory; assuming NIS provides encryption or strong security by default (it does not). Modern deployments may favor LDAP/Kerberos for stronger security and scalability. Final Answer: Both A and B are correct.

Question 11

UNIX text utilities: Which wc option reports only the number of lines in a file (line count output)?

Accepted Answer

Introduction / Context: The wc (word count) utility summarizes text by reporting lines, words, and bytes. When scripting or auditing logs, you often need just the number of lines. Knowing the correct option avoids parsing extra fields. Given Data / Assumptions: wc supports multiple flags to control what counts are shown. We want line count only. Input is a regular text file or standard input. Concept / Approach: By default, wc filename prints three numbers: lines, words, and bytes. The -l option restricts output to the line count. Other options are -w for words and -c for bytes (or -m for characters on some systems). Step-by-Step Solution: To count lines: wc -l file.txtTo count words: wc -w file.txtTo count bytes: wc -c file.txtTo count lines from a pipeline: grep error app.log | wc -l Verification / Alternative check: Use nl -ba file.txt | tail -1 to verify the highest printed line number equals the line count. Alternatively, awk 'END{print NR}' file.txt also returns the number of lines. Why Other Options Are Wrong: -r: Not a standard wc option. -w: word count, not line count. -c: byte count. None of the above: incorrect because -l is correct. Common Pitfalls: Using wc without options and then misreading the columns; confusing bytes and characters on multibyte encodings; counting lines in files that lack a trailing newline (tools may differ in edge handling). Final Answer: wc -l

Question 12

Viewing file beginnings: Which command prints the first lines (top portion) of a file on UNIX/Linux by default?

Accepted Answer

Introduction / Context: When inspecting configuration files or logs, you may only need the beginning of the file to verify headers or initial entries. UNIX/Linux provides head to quickly view the top lines without loading the entire file into a pager. Given Data / Assumptions: You want the first lines of a file (default often 10 lines). You are using standard POSIX utilities. File can be large, so a quick preview is desirable. Concept / Approach: The head command reads from the start of a file and prints the first N lines. You can adjust N with -n N. It is fast and useful in pipelines. Other commands like more or less page through content interactively; grep filters by pattern, not position. Step-by-Step Solution: Preview first lines: head file.txtSpecify count: head -n 20 file.txtCombine with tail for middle slices: head -n 1000 file | tail -n 20Use in pipelines: gunzip -c huge.gz | head Verification / Alternative check: Compare with less file.txt and jump to the beginning; both show the same initial content. head is non-interactive and terminates immediately after printing the requested lines. Why Other Options Are Wrong: grep: searches for patterns anywhere, not just the beginning. more: pager for interactive viewing. cat: dumps entire file; no line limit. None of the above: incorrect because head is correct. Common Pitfalls: Confusing -n with byte options on some platforms (e.g., -c counts bytes). Forgetting that default is typically 10 lines, which may differ by implementation. Final Answer: head

Question 13

Pipelines and redirection: Which UNIX command duplicates standard output to the terminal while simultaneously saving it to a file?

Accepted Answer

Introduction / Context: Sometimes you want to capture output for logs while still seeing it live. The tee utility solves this by splitting a stream: it writes to a file and passes the same data along to standard output. This is invaluable in pipelines and troubleshooting sessions. Given Data / Assumptions: The goal is to save command output to a file without losing on-screen visibility. You are using a POSIX shell and standard utilities. Overwriting vs appending may matter depending on workflow. Concept / Approach: Use a pipeline: command | tee file. tee writes its standard input to file and also to standard output, enabling further piping or terminal display. The -a option appends instead of overwriting. Step-by-Step Solution: Example: who | tee user.lstAppend mode: make build 2>&1 | tee -a build.logChain further: dmesg | tee dmesg.txt | grep errorVerify: view the file and confirm output also appeared on screen. Verification / Alternative check: Compare with redirection > (overwrites) or >> (appends) which do not mirror output to the screen. tee is unique in duplicating the stream. Why Other Options Are Wrong: grep: filters lines by pattern only. cat: displays files; does not duplicate streams to a file and stdout simultaneously without redirection tricks. more: pager for reading, not for splitting output. None of the above: incorrect because tee is correct. Common Pitfalls: Forgetting -a when you need to append; accidentally truncating logs. Not capturing stderr unless redirected (use 2>&1 to combine streams). Final Answer: tee

Question 14

IP addressing (classful): Which dotted format corresponds to a Class A network address layout?

Accepted Answer

Introduction / Context: Before Classless Inter-Domain Routing (CIDR) became ubiquitous, IPv4 used classful addressing: Class A, B, and C networks had fixed boundaries for network and host portions. Recognizing these formats is useful for legacy exams and understanding historical configurations. Given Data / Assumptions: IPv4 addresses are 32 bits, often written as four decimal octets. Class A: first octet is the network (8 bits), remaining three are hosts (24 bits). Question uses Net/Node placeholders to represent network vs host parts. Concept / Approach: In classful notation: Class A uses Net.Host.Host.Host, Class B uses Net.Net.Host.Host, Class C uses Net.Net.Net.Host. Therefore, for Class A, the correct pattern is Net.Node.Node.Node (one network octet followed by three host octets). Step-by-Step Solution: Recall classful splits: A=8/24, B=16/16, C=24/8.Map to dotted placeholders: A → Net.Node.Node.Node.Select the option that matches Class A. Verification / Alternative check: Example: 10.0.0.1 is a classic Class A private block; 10 is the Net, and 0.0.1 are Nodes/hosts. Why Other Options Are Wrong: Net.Net.Node.Node: Class B. Net.Net.Net.Node: Class C. Net.Node.Net.Node: Not a valid classful split. None of the above: incorrect because Net.Node.Node.Node is correct. Common Pitfalls: Confusing classful with CIDR, where boundaries can be at any bit. Mixing up B and C masks in memory; use the mnemonic A=1 Net, B=2 Nets, C=3 Nets (in octets). Final Answer: Net.Node.Node.Node

Question 15

Linux desktop selection (legacy Red Hat tools): Which utility allows a user to change the default X Window desktop environment/session?

Accepted Answer

Introduction / Context: Historically, some Linux distributions (notably Red Hat–based systems) provided a small utility to change the default X Window desktop or window manager without manual editing of startup scripts. Recognizing such tools is useful on certification exams and when maintaining older systems. Given Data / Assumptions: The system uses the X Window System with multiple desktop options (e.g., GNOME, KDE). There exists a distribution-provided helper to switch defaults. Names like utilinux or window are not standard desktop-switch tools. Concept / Approach: switchdesk is a utility that lets users select their preferred desktop environment, updating configuration so that the chosen desktop starts on the next login. While modern environments provide graphical display managers to select sessions, switchdesk was an accessible command-line/GUI helper in certain releases. Step-by-Step Solution: Run switchdesk or its GUI variant (where available).Choose the target desktop (e.g., GNOME, KDE).Log out and log back in to see the selected desktop start.If absent, adjust display manager session options or ~/.xinitrc manually. Verification / Alternative check: Inspect desktop session files under /usr/share/xsessions/ and confirm default symlinks or configuration changes after using switchdesk. Why Other Options Are Wrong: utilinux, cempre, window: Not standard tools for this task. None of the above: incorrect because switchdesk is the appropriate utility. Common Pitfalls: Expecting switchdesk on modern minimal installs; current systems often rely on display managers (GDM, SDDM, LightDM) to select sessions per login. Final Answer: switchdesk

Question 16

Terminology: In computing, what does the acronym OSS stand for?

Accepted Answer

Introduction / Context: Acronyms are common in technology, and understanding them helps in reading documentation and participating in technical discussions. OSS is a foundational term in software development culture and licensing. Given Data / Assumptions: We are discussing general software terminology. OSS refers to software whose source code is available under permissive or copyleft licenses. Alternative expansions listed are distractors. Concept / Approach: Open Source Software (OSS) is software released with a license that grants users rights to inspect, modify, and redistribute the source code, subject to license terms. This ecosystem encourages collaboration, transparency, and rapid iteration across communities and organizations. Step-by-Step Solution: Identify commonly accepted expansion: OSS → Open Source Software.Cross-check against distractors that are not standard industry terms.Select the standardized term. Verification / Alternative check: Consult recognized bodies (e.g., Open Source Initiative) and common usage across documentation, package managers, and repositories (GitHub, GitLab). Why Other Options Are Wrong: Open System Software, Original Source Software, Original System Server: Not standard expansions of OSS in this context. None of the above: incorrect because “Open Source Software” is correct. Common Pitfalls: Confusing OSS with FOSS (Free and Open Source Software) or with freeware (free of charge but not necessarily open source). Licensing rights vary; always read the license. Final Answer: Open Source Software

Question 17

Unix/Linux command-line basics: counting characters in a file  Which single wc option returns only the number of characters (bytes) in the specified file?

Accepted Answer

Introduction / Context: The wc utility (short for word count) is a standard Unix/Linux tool for quickly reporting basic text statistics. While many people use it to count lines or words, wc is equally useful for counting the number of characters (commonly interpreted as bytes in POSIX systems). This question tests recognition of the correct switch to retrieve only the character count. Given Data / Assumptions: The environment is a POSIX-like shell on Unix/Linux. We want only the number of characters in a given file, not lines or words. Default wc behavior and option meanings are assumed; locale and multibyte subtleties are noted but not the focus. Concept / Approach: wc supports separate flags for each statistic: -l for lines, -w for words, and -c for bytes (often referred to as characters). When invoked with a single flag, wc prints only that metric. Without flags, wc prints all three (plus the filename). Counting bytes is the most portable, as wc -c reports the number of bytes read from the file stream. Step-by-Step Solution: Identify the needed metric: characters as bytes.Choose the correct option: use wc -c file.txt.Interpret the output: a single integer (and filename, unless input is redirected).If you want just the integer, use redirection: wc -c < file.txt. Verification / Alternative check: As a sanity check, compare wc -c results with an alternate method such as using a programming language or summing byte counts from a hex dump. For small files without multibyte complications, the count should match exactly. Why Other Options Are Wrong: wc -r: not a standard wc option; it does not report character counts. wc -w: returns the number of words, not characters. wc -l: returns the number of lines, not characters. None of the above: incorrect because wc -c is valid and correct. Common Pitfalls: Confusing characters with lines or words, assuming -m is always available (some wc implementations also support -m for characters, but -c is the portable choice), or forgetting to handle filenames with spaces when scripting. Final Answer: wc -c

Question 18

Viewing a file in octal on Unix/Linux  Which single command displays a file’s contents in octal form (octal dump)?

Accepted Answer

Introduction / Context: System administrators and developers often need to inspect the raw bytes of a file. Unix provides a small, powerful tool to dump file contents in octal (and other bases). Recognizing the correct utility is fundamental to troubleshooting encodings, control characters, and binary formats. Given Data / Assumptions: You are working on a Unix/Linux system. You want to view a file in octal, optionally with other formats. No third-party tools are assumed; only standard utilities are considered. Concept / Approach: The command od (octal dump) is the standard utility for displaying file contents in octal by default. It can also show hexadecimal, ASCII, and other formats by providing options such as -t x1 for hex bytes or -An for suppressing addresses. It is ideal for spotting unprintable characters, line endings, and subtle binary differences. Step-by-Step Solution: Use the od command with a filename: od filename.Optionally add formatting flags, for example: od -An -t o1 filename for plain octal bytes.Scroll or pipe to a pager if the file is long: od filename | more.Interpret octal output to identify specific byte values or control characters. Verification / Alternative check: Compare od output with other tools such as hexdump or xxd where available. For octal-only needs, od’s default behavior is sufficient. Cross-check suspicious bytes by isolating a region with options like -j (skip) and -N (length). Why Other Options Are Wrong: oct: not a standard Unix command. of: not a viewer; resembles a dd operand name, not a standalone tool. cd: changes directories; unrelated to file dumping. None of the above: incorrect because od is correct and standard. Common Pitfalls: Assuming od only supports octal (it supports multiple formats), misreading addresses versus data, and forgetting to use options to suppress addresses or choose a display type suitable for the task. Final Answer: od

Question 19

Linux directory layout: location of device files  Which standard directory contains device files represented as special files in Unix/Linux?

Accepted Answer

Introduction / Context: Understanding the Filesystem Hierarchy Standard (FHS) is essential for Linux system administration. Device files are not typical data files; they are special files that provide an interface to hardware and kernel drivers. Knowing where they reside is foundational knowledge for troubleshooting and configuration. Given Data / Assumptions: The system resembles a standard Unix/Linux distribution following common FHS conventions. We need the directory that holds character and block device special files. We are not considering containerized or highly specialized minimal systems that virtualize device access elsewhere. Concept / Approach: Device files traditionally live under /dev. Entries like /dev/sda (block device), /dev/tty (character device), and many others map to hardware or virtual devices via the kernel. udev and related subsystems populate /dev dynamically at runtime, but the conventional path remains the same across distributions. Step-by-Step Solution: Identify the purpose: device special files.Recall FHS mapping: binaries in /bin, configuration in /etc, users in /home, devices in /dev.Select /dev as the correct directory.Verify by listing devices: ls -l /dev to see character (c) and block (b) devices. Verification / Alternative check: Run ls -l /dev and observe entries like /dev/null, /dev/zero, and storage devices. Compare with /bin (user binaries), /etc (configuration), and /home (user home directories) to confirm their distinct roles. Why Other Options Are Wrong: /bin: contains essential user binaries, not device nodes. /etc: contains system-wide configuration files. /home: contains user home directories. None of the above: incorrect because /dev is correct and standard. Common Pitfalls: Confusing /dev device nodes with mount points under /media or /mnt; assuming device files contain data like regular files; forgetting that permissions and ownership on /dev entries matter for access control. Final Answer: /dev

Question 20

Linux 2.2.x kernel: maximum size of a swap partition  For systems running Linux kernel series 2.2.x, what is the maximum size supported for a single swap partition?

Accepted Answer

Introduction / Context: Swap space extends virtual memory beyond physical RAM, enabling processes to run when RAM is fully utilized. Historical kernel versions imposed strict limits on the size of a single swap area. Administrators working with legacy systems must know these constraints to plan partitioning correctly. Given Data / Assumptions: The target system uses a Linux 2.2.x kernel. We are asking about a single swap partition, not the total of multiple swap areas. Standard swap partition format is used (not a swap file on unusual filesystems). Concept / Approach: Linux kernels have evolved in their swap area limits. In the 2.2.x era, a single swap partition supported up to approximately 2GB. Systems could employ multiple swap areas (activated via swapon) to increase total swap beyond this per-area cap, but each individual area had its own limit. Step-by-Step Solution: Identify kernel series: 2.2.x.Recall historical per-area swap limit for this series: 2GB.Note that multiple swap partitions can be combined to scale total swap capacity.Select 2GB as the correct maximum size for one swap partition. Verification / Alternative check: Consult man mkswap and historical kernel documentation for 2.2.x. Cross-reference with distribution release notes from that period, which typically confirm the 2GB per swap area limit and the ability to use several swap areas concurrently. Why Other Options Are Wrong: 128MB, 64MB, 32MB: reflect much older or different constraints; too small for 2.2.x capabilities. None of the above: incorrect because 2GB is the known limit for a single swap area in 2.2.x. Common Pitfalls: Confusing per-area limits with total swap limits; overlooking differences between swap partitions and swap files; failing to align swap size with RAM and workload needs on legacy systems. Modern kernels may have different limits, so always align guidance with the actual kernel version. Final Answer: 2GB

Linux Questions