Can (or should) I try to avoid Ubuntu server?

On Thu, 14 Aug 2008, Mark Madsen wrote:
[color=blue]
> On Thu, 14 Aug 2008 20:53:57 +1000, Res wrote:
>[color=green]
>> On Thu, 14 Aug 2008, Mark Madsen wrote:
>>[color=darkred]
>>> server, the existence of a root account with admin privileges provides
>>> a prime target for a cracker. There's nothing stopping one from
>>> preventing[/color]
>>
>> So you leave your desktop/servers exposed, you dont filter ssh ports,[/color]
>
> The technical term you are looking for is "straw man".[/color]

not in this part of the world
[color=blue]
>[color=green]
>> activating root account is still far safer then sudo in ubuntus default
>> setup as per my previous comment to the OP.[/color]
>
> The adjective you are looking for is "simplistic".[/color]

Simple to rape your ubuntu system, yep, totally agree there.


--
Cheers
Res

"The hopes we had, were much to high, way out of reach, but we have to
try, no need to hide, no need to run, cause all the answers come one by
one. The game will never be over, because we're keeping the dream alive"
-Freiheit

Sylvain Robitaille <syl@alcor.concordia.ca> wrote in
news:slrnga6f6u.bcn.syl@charlotte.concordia.ca:

[snip][color=blue]
> doing. On a few occasions, rather than invoking the UPGRADE.sh script
> as root, I selectively upgraded packages, but that really hasn't been
> necessary in a while. The output from the script running as non-root
> lets you know what would be updated if running as root, so it's easy to
> know if there's anything you want to be selective about.
>
> It's a tool, of course, and offered only because I hope it can be[/color]
useful[color=blue]
> to someone besides myself. Feel free to pilfer any portions of it that
> you find useful enough to add to your own script(s) rather than using
> mine as it is, if that's how it can be of use to you. :-)
>[/color]

I wrote something similar but less capable and with fewer options. ;v)
Mine simply outputs the (hopefully correct) upgradepkg line necessary to
handle _all_ of the packages _ever_ downloaded by Eric Hameleers'
rsync_slackware_patches.sh script. I capture the output of mine, usually
filtered by removing upgradepkg install_new and reinstall lines, and then
run that. Comments are very welcome. The 'if [1]' line shows that I had
originally tried a slightly different approach.

Before I present the script, I have one more question: Is there a
standard runlevel from which to run upgradepkg? 1? 3? It doesn't seem
clear to me which to pick, so I ask.

Offered in the same fashion as Sylvain's work, here is the script, with
my initials prefixing all variable names to avoid collisions:
#!/bin/sh

cd /home/ftp/pub/Linux/Slackware/slackware-12.1/patches/packages

for JRFNAME in `ls -rt1 *.tgz` ;
do
if [ 1 ] ; then
JRFPOSS=`basename $JRFNAME .tgz`
JRFSLV=`expr "$JRFPOSS" : '.*_\(slack.*\)$'`
JRFBLD=`expr "$JRFPOSS" : '.*-\([0-9]\+\)'`
JRFARC=`expr "$JRFPOSS" : '.*-\(.*\)-[0-9]'`
JRFVER=`expr "$JRFPOSS" : '.*-\(.*\)-.*-[0-9]'`
# JRFAPP=`expr "$JRFPOSS" : '\(.*\)-.*-.*-[0-9]'`
JRFAPP=`expr "$JRFPOSS" : "\(.*\)-$JRFVER"`
# echo poss=$JRFPOSS
# echo app =$JRFAPP
# echo ver =$JRFVER
# echo arc =$JRFARC
# echo bld =$JRFBLD
# echo slv =$JRFSLV
# ls -1 /var/log/packages/$JRFAPP*
if [ -a /var/log/packages/$JRFAPP-[0-9]* ] ; then
JRFOLD=`ls -1 /var/log/packages/$JRFAPP-[0-9]*`
JRFOLD=`basename $JRFOLD`
if [ $JRFOLD == $JRFPOSS ] ; then
echo upgradepkg --reinstall $JRFPOSS
else
echo upgradepkg $JRFOLD%$JRFPOSS
fi
else
echo upgradepkg --install-new $JRFPOSS
fi
fi
done

cd ~


--
The email address, above, is most certainly munged. Perhaps you
might reply to the newsgroup, instead? Thanks!

Hallo, james,

Du meintest am 15.08.08:
[color=blue]
> Before I present the script, I have one more question: Is there a
> standard runlevel from which to run upgradepkg? 1? 3? It doesn't
> seem clear to me which to pick, so I ask.[/color]

"That depends!" ...
Changing libraries: (mostly) runlevel 1
Changing (actually) running services (p.e. Samba): stopping the service
should be enough
Changing tools (like wireshark or vobcopy): no change of runlevel

And if you are workung on a terminalserver: runlevel 1.

Maybe I've forgotten a lot of other cases.

Viele Gruesse
Helmut

"Ubuntu" - an African word, meaning "Slackware is too hard for me".

james wrote:
[color=blue]
> Is there a standard runlevel from which to run upgradepkg? ...[/color]

If I have physical access to the system, and I'm worried that the
upgrade will affect something that is running (a daemon of some sort, a
significant library, etc.), I'll switch to run-level 1. If the machine
is remote, and I would have preferred to upgrade in run-level 1, I'll do
it in run-level 3, then reboot, crossing my fingers that it comes back
up (so far they always have).

Otherwise, I normally do upgrades in run-level 3, and occasionally even
in run-level 4 for some systems I manage that use that.

--
----------------------------------------------------------------------
Sylvain Robitaille [email]syl@alcor.concordia.ca[/email]

Network and Systems analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------

Thanks to both of you, Sylvain and Helmut. Your replies confirm the way
that I had been operating.

To recap for future search engine users:
Q: What runlevel to upgradepkg from?
A: The highest runlevel that isn't using the package you're upgrading, or
a lower runlevel, should be safe enough. In general, that means runlevel 1
for low-level libraries or system stuff, and 3 or 4 for program or utility
packages if the program or utility is stopped and nothing else is using a
part of what is to be upgraded.

If I've misquoted or misinterpreted please correct me. ;v)

Sorry for highjacking the thread. We'll now return this thread to reasons
to use Slackware!

--
The email address, above, is most certainly munged. Perhaps you
might reply to the newsgroup, instead? Thanks!