[sf-lug] NEED INFO ABOUT BOOT SECTOR, SPACE LIMITS
Rick Moen
rick at linuxmafia.com
Tue Aug 1 00:33:40 PDT 2017
Quoting Alex Kleider (akleider at sonic.net):
> I did that on my laptop (Ubuntu 14.4) and found 2362 items listed!!
> I'd be interested what others get on their machines.
> I'm quite sure I do not need/want all this stuff but am afraid of
> what might break if I start un-installing things.
apt-get has just the option for you! It's '--simulate', also usable
equivalently as option '--dry-run'.
Include that option for any 'apt-get remove' or 'apt-get --purge remove'
(or similar) command, and the tool will tell you what it _would_ have
done if that option weren't present. But under no circumstances will
any other action occur (with the option present).
FYI, in addition, if you say 'apt-get remove foo' and removing 'foo'
will also implicitly remove 'bar' that depends on 'foo', then you will
always, always, always be asked to confirm.
(Well, unless you include the -y aka --yes aka --assume-yes option that
explicitly means 'Just do it and don't ask me to confirm.)
Here's some other stuff from SVLUG's Web team documentation on
www.svlug.org. (I have no doubt it can be spiffed up, as it's a little
old.) For annoying historical reasons and against my preference,
it runs Ubuntu Server.
---<begin snip>---
PAY ATTENTION, here. SVLUG does its administration in a particular way
in order to conserve RAM and disk.
0. Before doing distro upgrades, e.g., from one Ubuntu Server LTS
release to the next, Web-search 'linode [new release number] upgrade',
to find custom Linode-written instructions, which you must follow
especially concerning kernels. Anything there overrides anything said here.
1. Don't install 'aptitude'. Don't install friggin' X11. This is a
headless server with the minimum possible software.
2. Use apt-get, apt-cache, dpkg, dpkg-reconfigure. Yes, we're
painfully aware that you probably use aptitude or kpackage or synaptic
or something. Yes, we know that Ubuntu deprecates apt-get (and that
Debian did at one time). We use small, reliable tools because we don't
have elbow room for the bloated ones.
Your regular command (as the root user) to update all installed files to
current versions on the package mirrors should be:
apt-get update && apt-get dist-upgrade
3. Occasionally check for unnecessary packages (as the root user):
apt-get autoremove #finds unneeded dependencies
deborphan #finds unneeded libs: Consider running
# "apt-get --purge remove $(deborphan)"
debfoster
(WARNING: dhcp3-client, dhcp3-common, and nsd* are essential packages
regardless of what the above may claim.) Suggestion: Run all three
in sequence repeatedly until they cease to find new unwanted packages.
The last of these tools (debfoster) is a very sophisticated and useful checker.
_However_, you must pay close attention when using it, or you might remove
something vital to the system.
Also useful along those lines:
dpkg --purge [packagename]
...will remove vestigial package conffile and similar directories left
over after you've removed the packages associated with them. You can
spot such leftovers by doing 'dpkg -l | more' and spotting any line
beginning with 'rc' in the leftmost column. That indicates run
control (init) and similar files left over from a removed package.
This will remove all vestigial 'rc' files for removed packages:
dpkg -l | grep ^rc | awk {'print $2'} | xargs dpkg --purge
(If you get a diagnostic about dpkg that starts out 'dpkg: --purge needs
at least one package name argument', that means there were no vestigial
'rc' packages.)
Once you're done with that cleanup, read down the list of installed
packages, and test whether any are unneeded and can be removed.
dpkg -l | less # You'll want a wide window for this.
Try 'apt-get remove [packagename]' for packages that seem unwanted:
If dependencies make it a bad idea, apt-get will make that obvious and
ask your confirmation. E.g., package 'plymouth' is a graphical bootup
utility that's pointless on a headless server, but critical system
packages depend on it. [Insert rude comment about Ubuntu mentality,
here.]
Examples of packages removed:
gcc-4.2-base
python2.4-minimal
python2.5-minimal
Last, this will purge the package cache (saving us significant disk),
i.e., delete everything but the lock file from /var/cache/apt/archives/
and /var/cache/apt/archives/partial/. Run the command when you're done
for the day with package operations:
apt-get clean
4. Make damned sure, when you tweak system software packages, that you
haven't accidentally launched a bunch more daemons. Do 'ps auxw | more'
to check. Is there something new running? Are you _sure_ it needs to
run? In the past, volunteers have accidentally enabled both xinetd and
eight large cgi-php daemons while working on the system. Don't do that.
5. You will occasionally want to run 'do-release-upgrade' as the root
user, to check for a newly available Ubuntu Server branch and transition
to it. If do-release-upgrade informs you of an upgrade option, that
would be an utterly excellent time to cancel and (before re-running
'do-release-upgrade') grab these and copy them offsystem as a
last-resort fallback option in case something goes terribly wrong:
(As root:)
dpkg --get-selections "*" > /root/selections-$(date +%F)
tar cvzf /root/etc-$(date +%F).tar.gz /etc
tar cvzf /root/webroot-$(date +%F).tar.gz /var/www/svlug-main
tar cvzf /root/svnfiles-$(date +%F).tar.gz /var/svn
tar cvzf /root/sitedocs-$(date +%F).tar.gz /usr/local/src/site-docs
tar cvzf /root/rootsensitive-$(date +%F).tar.gz /root/sensitive
After doing 'do-release-upgrade' or any other major package
operations, it's wise to check at least these logfiles for problems:
/var/log/messages
/var/log/daemon.log
/var/log/user.log
/var/log/lighttpd/error.log
/var/log/lighttpd/svlug.org/error.log
Please note that 'do-release-upgrade' defaults to ignoring new LTS
releases for systems like ours that track LTS (see: /etc/lsb-release)
until the first point release, e.g., 12.04.1 as opposed to 12.04.
6. Do NOT compile/install local software. Or at least, if you
really think it's necessary, carefully document what/where/why within
our site-docs directory. And discuss it with the other volunteers.
We've repeatedly had to clean, e.g., spurious Perl and Python trees
from /usr/local/lib that seemed to exist for no better reason than some
idiot not bothering to use 'apt-cache search' or the
http://packages.ubuntu.com/ search engine to find and then install the
correct distro package.
---<end snip>---
More information about the sf-lug
mailing list