Best of Technical Support
When setting up a small home network (Red Hat 9),
where your only connection to the Internet is
through a dialed-PPP connection, what is the best
practice for picking a domain name for the network
so it won't clash with some valid domain name
when you're connected to the Internet? Is there
some kind of standard, internal-only domain name,
similar to a hostname of localhost for 127.0.0.1?
You do not need any name; your Internet access
will be fine without one. If you really want one,
then register yourself a domain name.
RFC 2606 reserves the .test top-level domain
for testing; no .test domains will be assigned
on the Internet. Or, if you don't want to pay
to register a domain, and you have a friend who's
into DNS, you could ask for a subdomain of one of
his or her domains.
Red Hat uses localdomain (your machine defaults to localhost.localdomain).
When using a cron job, I know a process is executed on a certain schedule.
Is there any way to execute a process once there has been a change in a
directory or file? If so, how would one do such a thing?
One way is to use Linux Directory Notification. You can find
documentation and examples in the Documentation/dnotify.txt file
under the kernel source.
You can have your cron or at job check one of the timestamps of the
file or directory. The easiest way do that in a shell script is to
use GNU find's "%T@" or "%C@" format specifiers. This returns
the modification date (%T) or the ctime (change status) date in
seconds since the epoch. You can specify a number of other date
formats if you like, but seconds since the epoch is handier for some
forms of date arithmetic.
A more-advanced approach would be to monitor the file or directory
access with FAM (file alteration monitor). See oss.sgi.com/projects/fam/faq.html, but this is beyond a
simple shell script.
My Mandrake system shows the following error when I try starting up Linux:
mount:error 22 mounting ext2 flags Kernel panic:no init found. Try passing init=option to kernel
I've successfully booted it three times, but thereafter it has stopped
booting and keeps showing this message. What can I do?
A Linux kernel mounts the root filesystem and runs a program named init, usually found in the /sbin directory. You could read the kernel sources to find the other three or four places were Linux looks for a program named init. You also could pass the kernel a command-line or bootloader option init=/bin/sh, or some other full path to a program that the kernel would try to load. That's what the rest of this error message is trying to tell you. The question becomes: Why is your kernel unable to find the init program? The most likely cause is you are trying to mount something other than the root filesystem. If you tried to boot up and you passed the kernel a root=/dev/hda6 ... or some other device/partition path to a valid filesystem that didn't have /sbin/init on it, this is exactly the error message you'd receive. Actually, if it also didn't have a /dev/ directory on it, you'd get another error message: “Warning: Unable to open initial console.” That is not a fatal error, but perhaps you also were getting that error and not noticing.
If you had a completely bogus root= directive, if there wasn't a Linux-supported filesystem there, you'd get a different error, something like: “VFS Kernel panic. Unable to mount root.”
Other possibilities are that you had the system set up correctly but accidently removed or renamed /sbin/init or the /sbin directory, or your filesystem is so corrupt that /sbin/init's directory entry or inode is inaccessible.
In any event, I'd boot from a rescue disk, possibly a BBC
(bootable business card), such as one you might download from www.lnx-bbc.org. Burn to a CD-ROM; a mini-CD or business card
format usually are used for these, but a full-sized disk will work too.
Boot from the BBC or Tom's Root/Boot (www.toms.net/rb), and
run fsck on each of your filesystems. Then, look them over and figure
out which one is really your rootfs. Next, try booting manually, passing
the paramaters root= and init= using your bootloader (GRUB or LILO).
Then try fixing the /boot/grub/menu.lst (grub.conf) or /etc/lilo.conf to
list the correct kernel parameters properly (if that turns out to be
the cause of the whole problem). While you have the system booted up from your BBC or other
rescue media, it would be a good time to ask yourself: Is there any data I haven't backed
up on these filesystems? Is now a good time to copy that data off to
some other media? In the worst case you can re-install.
There's no shame in saying: “My data is backed
up; I don't understand all this fscking and those bootloader config files.
Heck with it!” and then doing a re-install.
I am having trouble getting on-line. I am using Minicom and have
set up PPP (using Red Hat 6.1). When I dial with Minicom, it appears that
I connect, but then it asks for a login and password. I enter my user
login and a bunch of charactors pop up, but then after a minute, it
says “No carrier”. Any idea of what I am doing wrong?
You aren't doing anything wrong; you're simply not using the right
program for the task. Minicom is a terminal program; it cannot establish
a PPP session and allow you to be a client of the remote network. You
need a program like pppd, which should be part of your distribution. However,
because your distribution is relatively outdated, you may have problems
connecting to your ISP, depending on the version of pppd included. If so,
you should install a newer version of pppd or upgrade to a newer
distribution, depending on your skill and comfort level.
Try the graphical kpppd or something similar. You
also may want to update your distribution. Currenly
Red Hat 9.0 is out, and you will be pleasantly
surprised by it.
The company for which I work has a VPN that uses Microsoft's VPN server.
Is it possible to connect to this using Linux (Red Hat 9)?
Be sure to find
out which protocol they are using. The standard way of creating a VPN
with Microsoft products was the built-in PPTP. Recently, they
have adopted IPSec and L2TP.
Both answers as printed will work, but both assume the existence or
availability of a rescue floppy. If there isn't one, a fix can be made
with the first Red Hat install CD: 1) Boot from Red Hat 9 CD #1. 2) Type the boot
option linux rescue. 3) Choose whatever language
and keyboard options are relevant. 4) At the Rescue prompt, choose Skip.
5) At the shell prompt, type cd /mnt. 6) Type
mkdir sysimage. This folder could be named anything. However, Red Hat included a folder by
name for this reason back in Red Hat 7.3, so I'm including it here for
purposes. 7) Type mount /dev/WHATEVER sysimage/.
Mount your / partition here.
8) Type chroot sysimage.
9) Mount /usr and /boot partitions, if necessary.
10) Type grub or /sbin/grub.
11) Type root (hd0,0). This tells GRUB where to find
its second-stage loader and config files—in this
example, the first partition of the first hard disk.
12) Type setup (hd0).
GRUB is placed in the MBR of the first HS.
13) Type quit.
14) Type exit until you are logged out of all shells and Red Hat
reboots. info grub has a lot of good info that would
flesh out this bare-bones
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Hacking a Safe with Bash
- Django Models and Migrations
- Secure Server Deployments in Hostile Territory, Part II
- The Controversy Behind Canonical's Intellectual Property Policy
- Huge Package Overhaul for Debian and Ubuntu
- Shashlik - a Tasty New Android Simulator
- Home Automation with Raspberry Pi
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development