We might not all have used sysutils/hal or even known that it was mostly silently working in the background as any good daemon process should. Today marks the final nail in its coffin, as it has been deprecated for quite some time and alternatives rolled out and have now been in place for ages. If for nostalgia or familiarity or uncertainty any of us may still have or chose to have installed it after it was already set on its journey to eventual FreeBSD expiration, there will be a little cleanup to do on our own systems. Surely we can all safely remove sysutils/hal if it remains, and that is a very simple operation.
pkg remove hal
The next two adjustments are likely less familiar to most
users. We need to remove haldaemon as both a user and a
group. Since I knew how to edit the password file with
vipw
(which incorporates use of vi), I used that to
remove the haldaemon line. It turns out that there is another
way that possibly ought to have been more obvious, but how often
does an admin who uses a pc alone with no other human users on
their system ever add or remove them? The command is
rmuser
but since my passwd
no longer includes haldaemon, I am not sure what it will do but I
suspect it will give an error.
rmuser: user (haldaemon) does not exist in the password database.
I have two choices, remove the group as a seperate operation as
I planned before discovering rmuser
or I could
re-create the haldaemon user, then use rmuser
which
should then work. I can show how both methods look, but we
can remove the group now and then re-create both user and group
before using rmuser
to see how that looks.
It turns out that editing the group file to revise or remove a
group is a fairly simple operation, we can use vigr
(which also incorporates use of vi), but lets create a haldaemon
account and group to show how rmuser
works.
When sysutils/hal was installed, it
automatically created the user and group haldaemon but did not also
create a home directory. We can simulate this by using
adduser
in a similar fashion, answering its prompts
the same as below or by using
pw useradd haldaemon -u 560 -g 560 -d /nonexistent -s
/sbin/nologin -c "HAL Daemon User"
since I did not remove the haldaemon group.
rmuser haldaemon
Matching password entry: haldaemon:*:560:560::0:0:HAL Daemon User:/nonexistent:/sbin/nologin Is this the entry you wish to remove? y Remove user's home directory (/nonexistent)? y Removing user (haldaemon): mailspool home passwd.
Checking the content of /etc/group
using vigr
proves that haldaemon group is no longer
present there. The above output also mentions the other
locations where haldaemon if present would be removed: mailspool,
home, and passwd. The next time a similar daemon, which is
presently devd, or any other daemon or user might need to be
removed, the same steps would be used. Further
information about account modification is available in the
FreeBSD handbook.
Since we have modified /etc/passwd
there is another thing we must do in order to keep our system
reliable. We need to synchronize those changes with /etc/master.passwd by using the command below (entire
path provided for precision but /usr/sbin/
can be omitted), more detail can be found by man 8
pwd_mkdb
which includes one option (-C) to simply verify no
errors were made with any edit.
/usr/sbin/pwd_mkdb -p /etc/master.passwd
One more detail that will be discovered with a reboot once all of the above is accomplished, that is, if your /boot/loader.conf (or possibly /etc/rc.conf) still has a line to start the hal daemon process. Edit the appropriate file to remove such a line as below and the forgotten step will not haunt you in the future, but if you received an error at boot, that it couldn't load hal or a similar error, you'd know how to fix it I hope but here I describe how.
hald_enable="YES"
No comments:
Post a Comment
Thank you for your interest!