Search
30 results for “npm”
Search results
Your AI Assistant Just Suggested a Package. Does It Actually Exist?
How AI-invented package names create a slopsquatting risk, and a practical npm and PyPI checklist for verifying dependencies before installation.
Why Every Container in Your Rolling Deploy Takes an Extra 10 Seconds to Stop
Why npm as PID 1 can prevent Node.js from receiving SIGTERM, trigger Docker's ten-second timeout, and end container shutdown with SIGKILL.
Your GitHub Actions Cache Hit Rate Is Worse Than You Think, and the Key Isn't the Problem
Why identical GitHub Actions cache keys still miss across pull requests, how branch scope and restore keys work, and the correct npm cache YAML.
Linux Process Management & systemd
Why SIGKILL cannot be caught the way SIGTERM can, and how systemd's Type= decides when a service actually counts as started.
What is the difference between a role and a policy in most cloud IAM systems?
The word "role" is provider-specific. In AWS, an IAM role is an assumable principal with policies attached. In Azure RBAC and Google Cloud IAM, a role is primarily a reusable collection of permissions; a role assignment or IAM policy binding grants that role to a principal at a scope. Always reduce the model to four questions: which principal, which permissions, on which resource scope, under which conditions. Translating the word "role" literally between providers causes dangerous design mistakes.
Linux Processes and Networking: Signals, Ports, Monitoring
How Linux Runs, Communicates, and Stays Alive.
Linux Storage & Filesystems: Disks, Partitions, Mounts, and Disk Usage
How Linux Stores Data, Mounts Disks, and Survives Failures.
NTFS Permissions and Mapped Drives in a Windows Domain
Design secure domain file sharing with NTFS permissions, group-based access control, and mapped drives on Windows Server 2019.
What does the principle of least privilege mean in practice, and why is it hard to maintain over time?
Least privilege means granting an identity only the specific permissions it needs to do its job, nothing broader "to be safe" or "to save time." It's hard to maintain because permissions tend to accumulate, someone gets a broad role to unblock a one-time task and it's never revoked, or a service starts with wildcard permissions during initial development and nobody narrows them before shipping. Maintaining least privilege requires ongoing review (access audits, unused-permission detection), not just a careful initial setup, because the natural drift over time is always toward more access, not less.
Why is publishing a port with `-p 8080:80` different from the container just "having" port 80?
A container's ports exist only on its own private network namespace by default; nothing on the host or outside can reach them until Docker explicitly forwards a host port to it. `-p 8080:80` tells Docker's network layer to forward the host's port 8080 to port 80 inside the container's namespace, host port first, container port second. Leaving a port `EXPOSE`d in a Dockerfile only records metadata/documentation, it has no effect on connectivity at all: another container on the same Docker network can already reach any port the first container is listening on, EXPOSE or not. Publishing to the host is the one thing that always requires an explicit `-p`.
At what point in the Terraform workflow are Sentinel (or similar policy-as-code) checks evaluated, and why does that timing matter?
Policy checks evaluate against the plan, the output of `terraform plan`, before `terraform apply` actually provisions anything, which means a policy violation blocks the run from proceeding to apply at all. Evaluating against the plan rather than the already-applied state is what makes this a preventive control instead of a detective one; the non-compliant resource is stopped before it exists, not flagged for cleanup afterward once it's already live and potentially already been exploited or has already incurred cost.
What is the difference between a Pod, a Deployment, and a Service?
A Pod is the smallest deployable unit, one or more containers that share network and storage, scheduled together onto a node. Pods are ephemeral and disposable; Kubernetes recreates them freely and their IPs change every time. A Deployment manages a set of identical Pods (a ReplicaSet under the hood), handling rolling updates, rollbacks, and keeping the desired replica count running even as individual Pods die. A Service gives that changing set of Pods a stable network identity, a fixed virtual IP and DNS name, so other things in the cluster don't need to track individual Pod IPs, which change constantly.
What is the difference between the Baseline and Restricted Pod Security Standards levels, and why are they cumulative?
Baseline blocks the most well-known container privilege-escalation paths, privileged containers, host namespaces, hostPath volumes, dangerous Linux capabilities, while still allowing a fairly permissive pod spec otherwise. Restricted inherits every Baseline rule and adds real hardening on top: it requires running as non-root, forbids privilege escalation outright, requires a restricted seccomp profile, and requires dropping all Linux capabilities except NET_BIND_SERVICE. A read-only root filesystem is not part of either standard, it's a separate hardening measure some organizations layer on as their own policy, on top of, not as part of, Restricted. They're cumulative by design, Restricted is Baseline plus more, so a workload that passes Restricted automatically satisfies Baseline too, and a cluster can apply different levels per namespace based on how much a given workload can be trusted.
If no NetworkPolicy exists in a namespace, what traffic is allowed between pods, and what changes the moment one NetworkPolicy is applied?
With no NetworkPolicy at all, pods are non-isolated: every pod can send and receive traffic from any other pod, with no restriction in either direction. The moment any NetworkPolicy selects a pod for a given direction (ingress or egress), that pod becomes isolated for that direction specifically, and only the traffic explicitly allowed by an applicable policy's rules gets through from then on; unrelated pods elsewhere in the cluster that no policy selects remain fully open. This is why introducing NetworkPolicy incrementally, rather than all at once, tends to break things: the first policy applied to a namespace can silently cut off traffic nobody had previously needed to declare.
What is the difference between killing a process with SIGTERM and SIGKILL?
`kill <pid>` sends SIGTERM by default, a request asking the process to shut down, which well-behaved programs catch to close files, finish in-flight work, and exit cleanly. `kill -9 <pid>` sends SIGKILL, which the kernel delivers directly and a process cannot catch, ignore, or clean up after; it is terminated immediately, mid-instruction if necessary. SIGKILL is a last resort for a genuinely hung process; reaching for it by default risks corrupted files or orphaned resources that a graceful SIGTERM shutdown would have avoided.
Why does sending SIGKILL to a stuck process work when SIGTERM doesn't, and what does that cost you?
SIGTERM asks a process to terminate but can be caught by a signal handler, letting the process run its own cleanup logic (closing files, flushing buffers, releasing locks) before actually exiting, or in a broken process, being caught and never acted on at all. SIGKILL cannot be caught, blocked, or ignored under any circumstances, the kernel terminates the process directly, which is why it works on a process SIGTERM couldn't reach. The cost is that none of that cleanup logic runs, a database connection isn't closed cleanly, a temp file isn't removed, a lock isn't released, so SIGKILL is a last resort after SIGTERM has been given a real chance to work, not a default first move.
In a systemd unit, what is the practical difference between Type=simple and Type=forking, and why does that distinction matter for dependency ordering?
With Type=simple, systemd considers the unit started the moment the main process is forked off, it does not wait for the application to finish its own initialization, so anything depending on that unit might start before the service is actually ready to handle requests. Type=forking expects the traditional daemon pattern, the initial process forks and exits once it judges its own startup complete, so systemd marks the unit started as soon as that original process exits successfully, while the actual daemon keeps running as a separate, now-orphaned process. That only tracks the daemonization handoff, not genuine application readiness, a process can exit believing setup is done while it is still finishing initialization in the background, so Type=forking is a better signal than Type=simple but still not a readiness guarantee. Type=notify is the one that actually is readiness-safe: the service explicitly calls sd_notify to tell systemd exactly when it's ready, rather than systemd inferring readiness from process exit behavior at all.
What is the practical difference between ps -ef and ps aux, and why do they show different columns for the same processes?
`-ef` is UNIX-style syntax and `aux` is BSD-style syntax for the same underlying command, and they weren't designed as one consistent interface; mixing them can even be ambiguous depending on other options used. The manual is explicit that BSD-style options change the default output to include process state (STAT) and full command arguments (COMMAND) instead of just the executable name, and BSD-style selection also defaults to showing every process the invoking user owns across all terminals, while UNIX-style selection defaults to processes on the current terminal only. Neither is "more correct," they're two different historical option conventions layered onto the same command, which is why picking one and being consistent about it matters more than which one.
What is a managed identity, and what problem does it solve compared to a service principal with a client secret?
A managed identity is an Entra ID identity automatically managed by Azure for a resource (a VM, an App Service, a Function), with credentials that Azure handles entirely, no client secret is ever stored, retrieved, or rotated by the application. A traditional service principal with a client secret requires that secret to be stored somewhere (a config file, a key vault) and rotated manually or via automation, which is itself a credential-management burden and a leak risk. Managed identities remove that burden for the common case of "this Azure resource needs to authenticate to another Azure service," which is why they're preferred whenever the workload runs on Azure compute.
Why is storing Terraform state locally a problem for a team, and what is the standard fix?
Local state is a single file on one person's machine, so another engineer can apply against stale or missing state and create conflicting changes. The standard fix is a remote backend that stores state centrally and supports locking. For the S3 backend, current Terraform supports native lock files with `use_lockfile = true`; DynamoDB-based locking is deprecated. The backend should also encrypt state and keep recoverable versions because state can contain sensitive values.
What is the difference between terraform plan and terraform apply, and why does that separation matter?
`plan` computes and displays the diff between current state and desired config without changing anything; it is a dry run. `apply` executes that diff against real infrastructure. Separating them means a human (or a CI approval gate) can review exactly what will be created, changed, or destroyed before anything actually happens, which is the core safety mechanism that makes infrastructure-as-code safer than manually clicking through a cloud console, nothing changes without a reviewed, explicit plan.
Linux Security and Hardening: SSH, Firewalls, Permissions
How Linux Protects Itself and How Administrators Make It Safer.
Linux Hands-On Labs: Users, Permissions, sudo, and Services
Linux Core Operations: Full Practical Labs (Beginner → Intermediate)
Automating Active Directory User and Group Management with PowerShell
Step-by-step lab: creating users, OUs, security groups, and group memberships using PowerShell
Cloud Computing Explained: Models, Architecture, and Security
What cloud computing actually is: service and deployment models, core architecture, security, and how platforms like Azure fit real workloads.
Why does data written inside a container disappear when the container is removed?
Anything a container writes lands in its own writable layer, which is deleted along with the container by `docker rm`. That is deliberate; it is what makes containers disposable and reproducible, a fresh container from the same image always starts from the same known state. Anything that actually needs to survive a container's lifecycle (a database's data files, uploaded assets) has to live outside that writable layer, in a named volume or a bind mount, which Docker mounts into the container at a chosen path but manages independently of the container itself.
What makes a workflow "GitOps" rather than just "we deploy from CI"?
The defining property is a pull-based reconciliation loop, not just that Git triggers a deploy. A GitOps agent (Argo CD, Flux) runs inside the cluster and continuously compares the live state against what's declared in a Git repository, pulling and applying any drift, with or without a new commit. A CI pipeline that runs `kubectl apply` on push is push-based: it changes things once, on trigger, and has no ongoing awareness of whether the cluster later drifts from that state. GitOps closes that loop continuously and treats Git, not the cluster, as the source of truth.
How does GitOps make rollbacks different from a traditional deployment rollback?
In a traditional deploy, rolling back means re-running a deployment process with an older artifact reference, a distinct operation from a normal deploy. In GitOps, a rollback is just a Git revert: since the desired cluster state is fully described by the repository at any commit, reverting to a previous commit and letting the reconciliation loop pick it up produces the previous cluster state through the exact same mechanism as any other change. There is no separate "rollback pipeline" to maintain or that can itself have bugs.
Production-Ready AKS GitOps with Terraform and ArgoCD
The DevOps Project That Finally Made Kubernetes, GitOps, and Terraform Click
Linux Core Operations: Users, Permissions, sudo, Services
Learn core Linux operations through structured hands-on labs: users, permissions, sudo, package management, and services.