Marek: Do you know of an automatic program for resetting hostname?

[Tom McDonald]

Marek, or anyone else,

I reset the Linux hostname manually (for privacy reasons) but is there an
existing script that resets the hostname based on some algorithm or
random list that the script is provided?

Here's what I do manually to switch oldhostname to newhostname:
a. I change the /etc/hostname contents
b. I change the /etc/hosts file contents
c. I run the hostname command as sudo
d. I manually delete old KDE directories
rm -f ~/.kde/*oldhostname*

Two questions:
1. Did I miss anything?
2. Is there an existing script to change hostnames more easily?

[Marek Novotny]

Yeah, if it is pre-systemd then you're just missing /etc/sysconfig/network.

HOSTNAME={your new hostname}

Post systemd you'd use hostnamectl set-hostname {new hostname},
and then you'd restart the systemd-hostname.... Like, sudo systemctl
restart systemd-hostname.

You might check for a tool as well called, nmtui. It's basically a
network manager text ui tool. You might have it on your distro or you
might not. No idea.

As for a script... I suppose that could be done. Hostname isn't
universal on Linux distros in terms of what arguments it accepts. It's
kind of a pain in the ass if you ask me.

But I tend to set this once, at install or right after if I screw up and
never think about it again. So a script that changes the hostname isn't
something I have thought about.

Are you not able to set your hostname for some reason?

--
Marek Novotny
https://github.com/marek-novotny

[Tom McDonald]

Marek Novotny wrote:

> Are you not able to set your hostname for some reason?

How did you know?

What's happening is, after I do the four things I listed,
whenever I open an xterm, I *still* get a complaint about the
*old* hostname screwing up something, I don't know what.

$ xterm
_IceTransSocketUNIXConnect: Cannot connect to non-local host old
_IceTransSocketUNIXConnect: Cannot connect to non-local host old
Warning: Tried to connect to session manager, Could not open network socket

So, even though the *new* hostname is "new", the old hostname "old"
is causing problems!

So, there must be more steps than those that I did on Kubuntu/KDE.

$ lsb_release -a
LSB Version: ...amd64...
Description: Ubuntu 14.04.2 LTS
Release: 14.04
Codename: trusty

What I did was:
a. Change /etc/hostname
FROM: old
TO: new
b. Change /etc/hosts
FROM: 127.0.1.1 old
TO: 127.0.1.1 new
c. Change hostname:
sudo hostname new
d. Delete KDE dotfiles:
rm -f ~/.kde/*old*
e. Change sudoers.d files:
sudo chmod 777 /etc/sudoers.d/*
sudo echo "$(whoami) $(hostname) = (root) NOPASSWD: $(type -p ifconfig)" >> /etc/sudoers.d/README
sudo chmod 0440 /etc/sudoers.d/*

What did I *need* to do to not get the xterm error?
_IceTransSocketUNIXConnect: Cannot connect to non-local host old
Warning: Tried to connect to session manager, Could not open network socket

[Tom McDonald]

Marek Novotny wrote:

> Post systemd you'd use hostnamectl set-hostname {new hostname},
> and then you'd restart the systemd-hostname.... Like, sudo systemctl
> restart systemd-hostname.

This is the step that confuses me!

$ sudo systemctl restart systemd-hostname
=> sudo: systemctl: command not found

$ sudo hostnamectl restart systemd-hostname
=> Unknown operation restart

I have been *manually* modifying the README in /etc/sudoers.d this way:
$ sudo chmod 777 /etc/sudoers.d/*
$ sudo gedit /etc/sudoers.d/README (remove the last line & replace with results from below...)
$ sudo echo "$(whoami) $(hostname) = (root) NOPASSWD: $(type -p ifconfig)" >> /etc/sudoers.d/README
$ sudo chmod 0440 /etc/sudoers.d/*

Do your suggested "ctl" commands *replace* those manual steps above?
$ sudo chmod 777 /etc/sudoers.d/*
$ sudo hostnamectl set-hostname new
$ sudo systemctl restart systemd-hostname <== this fails
$ sudo chmod 0440 /etc/sudoers.d/*

[Marek Novotny]

On 2015-10-16, Tom McDonald <kil...@gmail.com> wrote:

Okay, you missed something I wrote above for you though.

sudo vim /etc/sysconfig/network

HOSTNAME=

Did you change that?

[Marek Novotny]

On 2015-10-16, Tom McDonald <kil...@gmail.com> wrote:

You're on 14.04. I don't think that's a systemd based release. Just
ignore all that.

[Tom McDonald]

Marek Novotny wrote:

> You might check for a tool as well called, nmtui. It's basically a
> network manager text ui tool. You might have it on your distro or you
> might not. No idea.

The nmtui tool isn't on Kubuntu 14.04 yet...

$ apt-cache search nmtui;dpkg -l |grep nmtui
reports nothing

$ sudo apt-get install nmtui
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package nmtui

[Marek Novotny]

On 2015-10-16, Tom McDonald <kil...@gmail.com> wrote:

no. I wasn't sure if you were on a systemd system or not. But you're
not.

I'm off for a few hours. So look into /etc/sysconfig/network and I'll be
back in a few hours to check on you.

[Tom McDonald]

Marek Novotny wrote:

> Okay, you missed something I wrote above for you though.
>
> sudo vim /etc/sysconfig/network
>
> HOSTNAME=
>
> Did you change that?

I forgot to mention that this file did not exist, so I didn't
know what to do with the information you provided.

$ ls /etc/sysconfig
ls: cannot access /etc/sysconfig: No such file or directory

$ ls /etc/sysc*
/etc/sysctl.conf

/etc/sysctl.d:
10-console-messages.conf 10-magic-sysrq.conf 30-baloo-inotify-limit.conf
10-ipv6-privacy.conf 10-network-security.conf 30-nepomuk-inotify-limit.conf
10-kernel-hardening.conf 10-ptrace.conf README
10-link-restrictions.conf 10-zeropage.conf

[Tom McDonald]

Marek Novotny wrote:

> You're on 14.04. I don't think that's a systemd based release. Just
> ignore all that.

It was my mistake not to mention the release version.
Here is my tutorial below (that needs to be improved).

I think step 7 is the one step that is screwed up the most.
I don't really understand it as two methods were suggested in the past.
Any advice to clarify step 7?

Do you think step 7 is the reason for the xterm errors?

_IceTransSocketUNIXConnect: Cannot connect to non-local host old
Warning: Tried to connect to session manager, Could not open network socket

Change hostname (current method):

0. Decide on a new hostname:
FROM: old
TO: new

1. Find your current fqdn/hostname:
$ hostname -f
=> old

2. Change the /etc/hosts file:
$ sudo vi /etc/hosts

FROM: 127.0.1.1 old
TO: 127.0.1.1 new

3. Change the /etc/hostname file:
$ vi /etc/hostname
FROM: old
TO: new

4. Run the hostname command:
$ sudo hostname new

5. Remove /tmp/ hostname related files and directories:
rm /tmp/old.socket
rm -rf /tmp/kde-old/
rm -rf /tmp/ksocket-old/
rm -rf /tmp/orbit-old/
rm -rf /tmp/akonadi-old/

6. Remove ~/.kde hostname related directories:
$ rm -f ~/.kde/*old*
./home/uname/.kde/cache-old: Is a directory
./home/uname/.kde/tmp-old: Is a directory
./home/uname/.kde/socket-old: Is a directory

7. Change the sudoers.d directory files:
NOTE: Be very careful and do not proceed if you get any syntax errors!
$ ls -l /etc/sudoers.d/*
-r--r----- 1 root root 1000 Jan 1 12:01 README

Temporarily change permissions:

$ sudo chmod 777 /etc/sudoers.d/*

$ sudo hostnamectl set-hostname set

$ sudo systemctl restart systemd-hostname

$ sudo chmod 0440 /etc/sudoers.d/*

This appends the following line (where uname is the username & hostname is the hostname):

$ sudo echo "$(whoami) $(hostname) = (root) NOPASSWD: $(type -p ifconfig)" >> /etc/sudoers.d/README

=> uname hostname = (root) NOPASSWD: /sbin/ifconfig

Return all files to the original permissions:

[Marek Novotny]

On 2015-10-16, Tom McDonald <kil...@gmail.com> wrote:

> Marek Novotny wrote:
>
>> Okay, you missed something I wrote above for you though.
>>
>> sudo vim /etc/sysconfig/network
>>
>> HOSTNAME=
>>
>> Did you change that?
>
> I forgot to mention that this file did not exist, so I didn't
> know what to do with the information you provided.
>
> $ ls /etc/sysconfig

Okay, then I think you changed /etc/hosts and /etc/hostname already.
Likely Ubuntu's way. I'm more used to rhel.

sudo hostname {new hostname}
edit /etc/hosts
- change 127.0.1.1 {new hostname}

edit /etc/hostname
{new hostname}

I think that's all you'd need for your distro. Be back in a while.
Sorry.

[Marek Novotny]

On 2015-10-16, Tom McDonald <kil...@gmail.com> wrote:

Very quickly, and then I have to go. Step 7 I don't even know why you're
doing that. I've never done anything like step 5 or 6 either. I sent a
message just before this one, which lists all the steps I think you
need. Just three.

[Melzzzzz]

Do you have hostname command? I have `hostname` on my Manjaro install.
[bmaxa@maxa-pc asm]$ hostname --usage
Usage: hostname [-adfisy?V] [-F FILE] [--aliases] [--domain] [--fqdn]
[--long] [--file=FILE] [--ip-addresses] [--short] [--yp] [--nis]
[--help] [--usage] [--version] [NAME]

[Tom McDonald]

Marek Novotny wrote:

> I think that's all you'd need for your distro. Be back in a while.

Here is my tutorial, at the moment (step 7 & 8 are the problem).
----------------------------------------------------------
How to change the hostname on the fly on Kubuntu 14.04/KDE:

0. Decide on a new hostname:
FROM: old
TO: new

1. Find your current fqdn/hostname:
$ hostname -f
=> old

2. Change the /etc/hosts file:

$ sudo vi /etc/hosts

FROM: 127.0.1.1 old
TO: 127.0.1.1 new

3. Change the /etc/hostname file:

$ sudo vi /etc/hostname
FROM: old
TO: new

4. Run the hostname command:
$ sudo hostname new

5. Remove /tmp/ hostname related files and directories:

$ rm -rf /tmp/*old*

(individually)

rm /tmp/old.socket
rm -rf /tmp/kde-old/
rm -rf /tmp/ksocket-old/
rm -rf /tmp/orbit-old/

rm -rf /tmp/akonadi-old.*/

Note that this leaves:
/tmp/config-err-######
/tmp/gpg-######
/tmp/pulse-######

6. Remove ~/.kde hostname related directories:
$ rm -f ~/.kde/*old*
./home/uname/.kde/cache-old: Is a directory
./home/uname/.kde/tmp-old: Is a directory
./home/uname/.kde/socket-old: Is a directory

7. Change the sudoers.d directory files:

This should work, but it does not:
a. $ sudo chmod 777 /etc/sudoers.d/*
b. $ sudo hostnamectl set-hostname new
c. $ sudo systemctl restart systemd-hostname
=> the "systemctl" command is not found
d. $ sudo chmod 0440 /etc/sudoers.d/*

Since that fails, do it manually:

NOTE: Be very careful and do not proceed if you get any syntax errors!

$ ls -l /etc/sudoers.d/*
-r--r----- 1 root root 1000 Jan 1 12:01 README

-r--r----- 1 root root 1000 Jan 1 12:01 vpn-ifconfig

$ sudo chmod 777 /etc/sudoers.d/*

This appends the following line (where "uname" is the username &
"hostname" is the hostname):
$ sudo echo "$(whoami) $(hostname) = (root) NOPASSWD: $(type -p ifconfig)" >> /etc/sudoers.d/README
=> uname hostname = (root) NOPASSWD: /sbin/ifconfig

$ vi /etc/sudoers.d/README
user1 old = (root) NOPASSWD: /sbin/ifconfig
<== remove that now-duplicate line above ==>
user1 new = (root) NOPASSWD: /sbin/ifconfig

Return all files to the original permissions:
$ sudo chmod 0440 /etc/sudoers.d/*

8. Test:

$ xterm
_IceTransSocketUNIXConnect: Cannot connect to non-local host old

[Tom McDonald]

Melzzzzz wrote:

> Do you have hostname command? I have `hostname` on my Manjaro install.
> [bmaxa@maxa-pc asm]$ hostname --usage
> Usage: hostname [-adfisy?V] [-F FILE] [--aliases] [--domain] [--fqdn]
> [--long] [--file=FILE] [--ip-addresses] [--short] [--yp] [--nis]
> [--help] [--usage] [--version] [NAME]

yes, I have hostname. It's not enough though, I think.

$ hostname --version
hostname 3.15

[Tom McDonald]

Marek Novotny wrote:

> I've never done anything like step 5 or 6 either.

My mistake.
One of those steps was for changing the USERNAME!

My mistake for including it (I'm doing both - but for now,
let's just look at the hostname).

So, here are the current steps, with the error:

How to change the hostname on the fly on Kubuntu 14.04/KDE:

0. Find your current fqdn/hostname:

$ hostname -f
=> old

1. Decide on a new hostname:
FROM: old
TO: new

2. Change the /etc/hosts file:
$ sudo vi /etc/hosts
FROM: 127.0.1.1 old
TO: 127.0.1.1 new

3. Change the /etc/hostname file:

$ sudo vi /etc/hostname

FROM: old
TO: new

4. Run the hostname command:
$ sudo hostname new

5. OPTIONALLY: Remove ~/.kde hostname related directories:

$ rm -f ~/.kde/*old*
./home/uname/.kde/cache-old: Is a directory
./home/uname/.kde/tmp-old: Is a directory
./home/uname/.kde/socket-old: Is a directory

6. Change the sudoers.d directory files:

This should work, but it does not:

a. $ sudo chmod 777 /etc/sudoers.d/*
b. $ sudo hostnamectl set-hostname new
c. $ sudo systemctl restart systemd-hostname <== the "systemctl" command is not found

d. $ sudo chmod 0440 /etc/sudoers.d/*

Since that fails, do it manually:

NOTE: Be very careful and do not proceed if you get any syntax errors!

$ ls -l /etc/sudoers.d/*
-r--r----- 1 root root 1000 Jan 1 12:01 README

-r--r----- 1 root root 1000 Jan 1 12:01 vpn-ifconfig

$ sudo chmod 777 /etc/sudoers.d/*

This appends the following line (where uname is the username & hostname is the hostname):
$ sudo echo "$(whoami) $(hostname) = (root) NOPASSWD: $(type -p ifconfig)" >> /etc/sudoers.d/README
=> uname hostname = (root) NOPASSWD: /sbin/ifconfig

$ vi /etc/sudoers.d/README
user1 old = (root) NOPASSWD: /sbin/ifconfig <== remove this now-duplicate line
user1 new = (root) NOPASSWD: /sbin/ifconfig

Return all files to the original permissions:
$ sudo chmod 0440 /etc/sudoers.d/*

7. Test:
$ xterm

[Wildman]

You should change your name to Stradivarius.

--
<Wildman> GNU/Linux user #557453
The cow died so I don't need your bull!

[Bit Twister]

On Fri, 16 Oct 2015 22:57:25 +0000 (UTC), Tom McDonald wrote:

> yes, I have hostname. It's not enough though, I think.
>
> $ hostname --version
> hostname 3.15

Just for fun, after you believe you have set the new host name, go
ahead and reboot the system.

[Marek Novotny]

On 2015-10-16, Tom McDonald <kil...@gmail.com> wrote:

Took me over two hours to get home. Holy cow. Okay. Is this still not
working for you? I'm downloading kubuntu 14.04 LTS and will try to do it
on that. Surprised this is a problem at all.

[Marek Novotny]

Hey Bit. Any words of wisdom while I wait for the iso to download?

[Marek Novotny]

On 2015-10-16, Tom McDonald <kil...@gmail.com> wrote:

Hi Tom,

Okay, new install of kubuntu 14.04 LTS.

Just the three steps mentioned worked fine for me.

sudo hostname {new hostname}
sudo vim /etc/hosts
change 127.0.1.1 {new host}
sudo vim /etc/hostname
change to {new hostname}

That works on the spot and survives a reboot just fine.

[Tom McDonald]

Marek Novotny wrote:

> Took me over two hours to get home. Holy cow. Okay. Is this still not
> working for you? I'm downloading kubuntu 14.04 LTS and will try to do it
> on that. Surprised this is a problem at all.

I'm guessing, Marek, that there's something that an xterm needs which isn't
known to me. Otherwise, why would an xterm complain about an old hostname.

If I *reboot* then everything is fine.
It's only when I change the hostname and then start an xterm.

However, it *would* be useful, in this post-Snowden day and age, for us
to have a script that changes the hostname daily, perhaps off a dictionary
or baby-name list, or any given list.

It just makes sense, from a privacy standpoint, that we change our
hostnames frequently.

Can you see a major *downside* to frequent scripted changes of the hostname?

[Tom McDonald]

Marek Novotny wrote:

> On 2015-10-16, Tom McDonald <kil...@gmail.com> wrote:
>
> Hi Tom,
>
> Okay, new install of kubuntu 14.04 LTS.
>
> Just the three steps mentioned worked fine for me.
>
> sudo hostname {new hostname}
> sudo vim /etc/hosts
> change 127.0.1.1 {new host}
> sudo vim /etc/hostname
> change to {new hostname}
>
> That works on the spot and survives a reboot just fine.

The reboot always fixed the problem.
Did you try an xterm in the interim?

a. Start with the old hostname
b. Switch to the new hostname
c. Then open an xterm

Did an xterm complain as mine did?

[Tom McDonald]

Marek Novotny wrote:

>> Just for fun, after you believe you have set the new host name, go
>> ahead and reboot the system.
>
> Hey Bit. Any words of wisdom while I wait for the iso to download?

Just to be clear, the error goes away *after* I reboot.
So, this works:

1. Start with old hostname
2. Change the hostname
3. Reboot

But, this gives an xterm error:
1. Start with old hostname
2. Change the hostname
3. Open an xterm

$ xterm
_IceTransSocketUNIXConnect: Cannot connect to non-local host old
_IceTransSocketUNIXConnect: Cannot connect to non-local host old
Warning: Tried to connect to session manager, Could not open network socket

Even so, it would be nice to have the hostname changed on every reboot.
Is there any downside to changing the hostname in this post-Snowden era?

[Bit Twister]

On Fri, 16 Oct 2015 18:22:35 -0700, Marek Novotny wrote:
> On 2015-10-17, Bit Twister <BitTw...@mouse-potato.com> wrote:
>>
>> Just for fun, after you believe you have set the new host name, go
>> ahead and reboot the system.
>
> Hey Bit. Any words of wisdom while I wait for the iso to download?

Hehehehe,
1 numerous applications need to know when the node name changes.
My recommendation, always reboot to insure everything is aware of change.
2 node names are changed manually by the human.
2 node names are changed via dhcp server.

[Marek Novotny]

On 2015-10-17, Bit Twister <BitTw...@mouse-potato.com> wrote:
> On Fri, 16 Oct 2015 18:22:35 -0700, Marek Novotny wrote:
>> On 2015-10-17, Bit Twister <BitTw...@mouse-potato.com> wrote:
>>>
>>> Just for fun, after you believe you have set the new host name, go
>>> ahead and reboot the system.
>>
>> Hey Bit. Any words of wisdom while I wait for the iso to download?
>
> Hehehehe,
> 1 numerous applications need to know when the node name changes.
> My recommendation, always reboot to insure everything is aware of change.
> 2 node names are changed manually by the human.
> 2 node names are changed via dhcp server.

Thanks Bit. Always good to read your contributions.

[Marek Novotny]

I didn't try xterm. I used konsole. You might restart the network.

$ sudo ifdown eth0 && sudo ifup eth0

assuming your interface is called, eth0 of course.

Regarding your post Snowden issue. Changing your hostname daily is a bit
much I think. Seems like a bit of work and no payoff.

I have something that will really cause your head to spin...

https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf

[William Unruh]

On 2015-10-17, Tom McDonald <kil...@gmail.com> wrote:

> Marek Novotny wrote:
>
>> Took me over two hours to get home. Holy cow. Okay. Is this still not
>> working for you? I'm downloading kubuntu 14.04 LTS and will try to do it
>> on that. Surprised this is a problem at all.
>
> I'm guessing, Marek, that there's something that an xterm needs which isn't
> known to me. Otherwise, why would an xterm complain about an old hostname.

Do you close down and relog into X after changing the hostname? If not
that could be the problem.

>
> If I *reboot* then everything is fine.
> It's only when I change the hostname and then start an xterm.
>
> However, it *would* be useful, in this post-Snowden day and age, for us
> to have a script that changes the hostname daily, perhaps off a dictionary
> or baby-name list, or any given list.
>
> It just makes sense, from a privacy standpoint, that we change our
> hostnames frequently.

Who but you cares what your hostname is? Your IP address is your "name"
as far as the outside world is concerned.

[Bit Twister]

On Sat, 17 Oct 2015 02:47:30 +0000 (UTC), Tom McDonald wrote:
>
> Just to be clear, the error goes away *after* I reboot.

Glad to hear that. If not, usual problem is files in $HOME are owned by
root because user did a "su" instead of "su - root" or "su -"

> So, this works:
>
> 1. Start with old hostname
> 2. Change the hostname
> 3. Reboot
>
> But, this gives an xterm error:
> 1. Start with old hostname
> 2. Change the hostname
> 3. Open an xterm
>
> $ xterm
> _IceTransSocketUNIXConnect: Cannot connect to non-local host old
> _IceTransSocketUNIXConnect: Cannot connect to non-local host old
> Warning: Tried to connect to session manager, Could not open network socket

Interesting. Then again, not using IceWm as Display Environment.

I am used to seeing Xauth type errors.

> Even so, it would be nice to have the hostname changed on every reboot.

Where do you feel the node name is being recorded for posterity.
As for your requirement, you can script a hostname change script and
call it during shutdown. Next boot would have the new name.

> Is there any downside to changing the hostname in this post-Snowden era?

Believe it or not, when your system is fingerprinted it is better to
not attempt to restrict information leakage.

I spent a day or so stopping leakage and was surprised when I was
more unique among less systems. :-(


Play around here http://panopticlick.eff.org/ and see for yourself.

Check out these two probes:

https://panopticlick.eff.org/index.php?action=log&js=yes
Your browser fingerprint appears to be unique among the 5,970,519 tested so far.

Currently, we estimate that your browser has a fingerprint that
conveys at least 22.51 bits of identifying information.

Now look what happens when I reduce the bits of identifying information.

Within our dataset of several million visitors, only one in 39,023
browsers have the same fingerprint as yours.

Currently, we estimate that your browser has a fingerprint that
conveys 15.25 bits of identifying information.


Your ISP is the best contact for LEO personnel to see if you are
the one they want.

As far as WiFi, your MAC address it better than a node name and is how
the hotspot knows to route information to your connection.

Verizon is back to tacking on a super cookie into your traffic to better
track your movements. Changing mac or node name is not going to help
hide what so ever.

[J.O. Aho]

On 10/16/2015 10:05 PM, Tom McDonald wrote:

> I reset the Linux hostname manually (for privacy reasons) but is there an
> existing script that resets the hostname based on some algorithm or
> random list that the script is provided?

Limited use of this IMHO, some local network devices could snap it up or
your MTA connecting to another, then your browser will be telling a lot
more about your machine and that without giving away a hostname.

>
> Here's what I do manually to switch oldhostname to newhostname:
> a. I change the /etc/hostname contents
> b. I change the /etc/hosts file contents

not really needed anything in your /etc/hosts

> c. I run the hostname command as sudo
> d. I manually delete old KDE directories
> rm -f ~/.kde/*oldhostname*
>
> Two questions:
> 1. Did I miss anything?

You may encounter some services which stops working when changing host name.

> 2. Is there an existing script to change hostnames more easily?

with little bash skills you can write your own.


--

//Aho

[Jasen Betts]

On 2015-10-16, Tom McDonald <kil...@gmail.com> wrote:

> Marek, or anyone else,

>
> I reset the Linux hostname manually (for privacy reasons) but is there an
> existing script that resets the hostname based on some algorithm or
> random list that the script is provided?
>

> Here's what I do manually to switch oldhostname to newhostname:
> a. I change the /etc/hostname contents
> b. I change the /etc/hosts file contents

> c. I run the hostname command as sudo
> d. I manually delete old KDE directories
> rm -f ~/.kde/*oldhostname*
>
> Two questions:
> 1. Did I miss anything?

environmwent variables and other state retained by processes started
before your changes. try logging out and back in.



--
\_(ツ)_

[crankypuss]

What a pain in the ass. I may be dumber than dog snot, but it seems to
me that any system that provides a parameter should also provide a means
of setting that parameter which does not include tiptoeing through a
parade of kludges.

--
http://totally-portable-software.blogspot.com [updated: too long ago]

[Tom McDonald]

William Unruh wrote:

> Do you close down and relog into X after changing the hostname? If not
> that could be the problem.

No. I only do the steps I posted prior.

Googling for closing & restarting X, I found this as the suggested method
for Kubuntu:

$ sudo /etc/init.d/lightdm stop
$ sudo /etc/init.d/lightdm start

However, looking at the "lightdm" file, it seems to have a "restart"
command, so, this should work:
$ sudo /etc/init.d/lightdm restart

I'll test that in a moment, but I want to send this first, just in case.

> Who but you cares what your hostname is? Your IP address is your "name"
> as far as the outside world is concerned

I'm trying to learn more about hotspot privacy, and, I plan on changing
the hostname, MAC, username, IP address, browser fingerprint, etc..

I'm just starting with the hostname, because I thought it would be the
easiest privacy protection change of all.

[Tom McDonald]

Tom McDonald wrote:

> $ sudo /etc/init.d/lightdm restart
> I'll test that in a moment, but I want to send this first, just in case.

I'm glad I sent the message first, as it hung the system.

I tried:
$ sudo /etc/init.d/lightdm restart
But, it hung the system.

I tried:
$ sudo /etc/init.d/lightdm stop
But it too hung the system.

Googling, I see I needed to be at a runlevel 3 (whatever that is)
command line for that X stop/restart to work, so, I don't think
stopping and restarting X is obvious from the Konsole.

However, the run levels seem to be *very* OS dependent, so, most
of the hits for Ubuntu won't work (it seems) for Kubuntu.

Anyway, I'll try dropping down to runlevel 3 with:

$ su root
# init 3

And *then* I'll run the lightdm "restart" command.

But first, I'll send this off because I forsee a few reboots in my
very near future...

[Bit Twister]

On Sat, 17 Oct 2015 12:30:55 +0000 (UTC), Tom McDonald wrote:
>
> Googling, I see I needed to be at a runlevel 3 (whatever that is)
> command line for that X stop/restart to work, so, I don't think
> stopping and restarting X is obvious from the Konsole.

Depending on release, default run level, It could be as simple as
Ctrl+Alt+Backspace with a double tap on the Backspace key.

> However, the run levels seem to be *very* OS dependent, so, most
> of the hits for Ubuntu won't work (it seems) for Kubuntu.

Not only Os dependent, but can depend on release of OS.

Systemd has blurred the line on runlevels. Basically, in laymen terms,
you have a GUI login, Non-GUI login and maintenance login.

I always boot run level 3 (non-gui) login and enter startx to get the
desktop environment running.

>
> Anyway, I'll try dropping down to runlevel 3 with:
>
> $ su root

Personally I would use "su - root" :)

> # init 3
>
> And *then* I'll run the lightdm "restart" command.
>
> But first, I'll send this off because I forsee a few reboots in my
> very near future...

I can recommend installing VirtualBox and use a guest to play around
with learning how to do things. The few seconds to boot/shutdown is a
real time saver and in the event you really screw something up, it is much
faster to re-install a guest than it is to re-install on your system.

You can have snapshots. That allows you to roll back to before the
last change or you can clone the install which I find handy for
upgrade testing.

[Marek Novotny]

On 2015-10-17, crankypuss <inv...@invalid.invalid> wrote:
> What a pain in the ass. I may be dumber than dog snot, but it seems to
> me that any system that provides a parameter should also provide a means
> of setting that parameter which does not include tiptoeing through a
> parade of kludges.

They are. A distribution is essentially a giant rolling release. The
kernel is updated ongoing. The shell is updated, less often, but still
it is. And how it works as a distro is also changed and enhanced
ongoing. Look at init > upstart > systemd. Look at NetworkManager.
Before there simply wasn't one. Now there is, and more and more you are
seeing a text UI for it. And in there you'll be able to change your host
name. But each distro is unique and follows the ideals of its creators.
They focus on what they feel is important or maybe it is as simple as
they had ex amount of time to ex amount of work and they are more
focused on other things. Eventually they will get to this.

Linux isn't standing still, but it isn't everything you think it should
be right now, today. We have to work on it and guide it. That is being
done.

With systemd it's just a command. And with nmtui it is a text ui and
from it you can set the hostname. Now, kubuntu 14.04 LTS is not up to
systemd, but later versions are. And I'm not sure which versions, if
any, support nmtui at this time. On rhel 7, I have both.

[Bit Twister]

On Sat, 17 Oct 2015 07:09:00 -0700, Marek Novotny wrote:
> On 2015-10-17, crankypuss <inv...@invalid.invalid> wrote:
>> What a pain in the ass. I may be dumber than dog snot, but it seems to
>> me that any system that provides a parameter should also provide a means
>> of setting that parameter which does not include tiptoeing through a
>> parade of kludges.

First, do not think the previous list of changes was required for a
node name change. Example, I would like to see the /etc/sudoers.d file
requiring a change.

Second, think of the node name as your social security number. You
change that and a whole bunch of organization need to know about the
change and yet how would the social security department know who all
is using your number and needs notifying.

The flexibility of networking and the installed applications is like the above.
The application know the best constant is node name within the system.
That is why you are seeing 127.0.0.1 localhost node_name_here in /etc/hosts.

Thanks to systemd, more and more OSs are forced to use /etc/hostname as
the one location for hostname but the applications only use the
hostname seen when they were started. Node name was not expected to
change during their "lifetime".

Looking in
$ grep hosts: /etc/nsswitch.conf
hosts: mdns4_minimal files nis dns mdns4 myhostname
you might notice several apps/methods of converting node name to ip
address which may be called to get node/ip to be used during
application to application communications on the node let alone nodes
on the LAN.

Last, but not least, be careful of what you ask for.
I have not checked lately, but at one time on my distribution, there was
a file trigger on the node name file. Imagine my surprise while in the
mist of name change, losing my desktop.

> They are. A distribution is essentially a giant rolling release. The
> kernel is updated ongoing. The shell is updated, less often, but still
> it is. And how it works as a distro is also changed and enhanced
> ongoing. Look at init > upstart > systemd. Look at NetworkManager.
> Before there simply wasn't one. Now there is, and more and more you are
> seeing a text UI for it.

Heheh, and about a month ago, I completed disabling network,
NetworkManager service and other network apps and moved to using
systemd-networkd.service. Reduced my boot time by 20 seconds.
Network restart now works reliably and happens in about a second.

> Linux isn't standing still, but it isn't everything you think it should
> be right now, today.

Yep, the only constant in Linux is change.

Imagine my surprise when _ip=$(hostname --ip-address) returned my ipv6
and ipv4 address when I thought I was only using ipv4 addressing.

[Marek Novotny]

On 2015-10-17, Bit Twister <BitTw...@mouse-potato.com> wrote:

I forget what script it was I was writing, but eventually I had to
change all my uses of wget to wget -4 because at some point, someone
started replying with ipv6 and of course the rest of the script was
expecting to use ipv4 addresses in arguments.

If anything, more and more I learn that I really have to be specific
about what I want in return for an answer. Live and learn the hard way.
:)

[Tom McDonald]

Marek Novotny wrote:

> Now, kubuntu 14.04 LTS is not up to
> systemd, but later versions are. And I'm not sure which versions, if
> any, support nmtui at this time.

This is good to know for the future.

[Tom McDonald]

Bit Twister wrote:

> $ grep hosts: /etc/nsswitch.conf
> hosts: mdns4_minimal files nis dns mdns4 myhostname

What does this file do?

Mine says:
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd: compat
group: compat
shadow: compat

hosts: files myhostname mdns4_minimal [NOTFOUND=return] dns mdns4
networks: files

protocols: db files
services: db files
ethers: db files
rpc: db files

netgroup: nis

[Tom McDonald]

Bit Twister wrote:

>> Anyway, I'll try dropping down to runlevel 3 with:
>>
>> $ su root
>
> Personally I would use "su - root"

Wondering what the difference is between:
$ su root
and
$ su - root

Here's what the manpage says about the dash:
"The optional argument - may be used to provide an environment
similar to what the user would expect had the user logged in
directly."

Specifically, it seems:
The value of $PATH is reset to /bin:/usr/bin for normal users,
or /sbin:/bin:/usr/sbin:/usr/bin for the superuser.

So, in layman's terms, I guess the dash sets the path to what
I am used to as a normal user.

Is that correct?

[Tom McDonald]

Bit Twister wrote:

> files in $HOME are owned by
> root because user did a "su" instead of "su - root" or "su -"

That's not in the manpage for "su" unfortunately, so, I don't
disbelieve you; it's just not obvious to me.

I'll start using "su -" instead of "su" from now on, but, what
you know about su must be tribal knowledge because the manpage
doesn't say it.

SU(1) User Commands SU(1)



NAME
su - change user ID or become superuser

SYNOPSIS
su [options] [username]

DESCRIPTION
The su command is used to become another user during a login session. Invoked without a
username, su defaults to becoming the superuser. The optional argument - may be used to provide

an environment similar to what the user would expect had the user logged in directly.

Additional arguments may be provided after the username, in which case they are supplied to the
user's login shell. In particular, an argument of -c will cause the next argument to be treated
as a command by most command interpreters. The command will be executed by the shell specified
in /etc/passwd for the target user.

You can use the -- argument to separate su options from the arguments supplied to the shell.

The user will be prompted for a password, if appropriate. Invalid passwords will produce an
error message. All attempts, both valid and invalid, are logged to detect abuse of the system.

The current environment is passed to the new shell. The value of $PATH is reset to /bin:/usr/bin
for normal users, or /sbin:/bin:/usr/sbin:/usr/bin for the superuser. This may be changed with
the ENV_PATH and ENV_SUPATH definitions in /etc/login.defs.

A subsystem login is indicated by the presence of a "*" as the first character of the login
shell. The given home directory will be used as the root of a new file system which the user is
actually logged into.

OPTIONS
The options which apply to the su command are:

-c, --command COMMAND
Specify a command that will be invoked by the shell using its -c.

The executed command will have no controlling terminal. This option cannot be used to
execute interractive programs which need a controlling TTY.

-, -l, --login
Provide an environment similar to what the user would expect had the user logged in
directly.

When - is used, it must be specified as the last su option. The other forms (-l and --login)
do not have this restriction.

-s, --shell SHELL
The shell that will be invoked.

The invoked shell is chosen from (highest priority first):

The shell specified with --shell.

If --preserve-environment is used, the shell specified by the $SHELL environment
variable.

The shell indicated in the /etc/passwd entry for the target user.

/bin/sh if a shell could not be found by any above method.

If the target user has a restricted shell (i.e. the shell field of this user's entry in
/etc/passwd is not listed in /etc/shells), then the --shell option or the $SHELL environment
variable won't be taken into account, unless su is called by root.

-m, -p, --preserve-environment
Preserve the current environment, except for:

$PATH
reset according to the /etc/login.defs options ENV_PATH or ENV_SUPATH (see below);

$IFS
reset to “<space><tab><newline>”, if it was set.

If the target user has a restricted shell, this option has no effect (unless su is called by
root).

Note that the default behavior for the environment is the following:

The $HOME, $SHELL, $USER, $LOGNAME, $PATH, and $IFS environment variables are reset.

If --login is not used, the environment is copied, except for the variables above.

If --login is used, the $TERM, $COLORTERM, $DISPLAY, and $XAUTHORITY environment
variables are copied if they were set.

Other environments might be set by PAM modules.


CAVEATS
This version of su has many compilation options, only some of which may be in use at any
particular site.

CONFIGURATION
The following configuration variables in /etc/login.defs change the behavior of this tool:

CONSOLE_GROUPS (string)
List of groups to add to the user's supplementary groups set when logging in on the console
(as determined by the CONSOLE setting). Default is none.

Use with caution - it is possible for users to gain permanent access to these groups, even
when not logged in on the console.

DEFAULT_HOME (boolean)
Indicate if login is allowed if we can't cd to the home directory. Default is no.

If set to yes, the user will login in the root (/) directory if it is not possible to cd to
her home directory.

ENV_PATH (string)
If set, it will be used to define the PATH environment variable when a regular user login.
The value is a colon separated list of paths (for example /bin:/usr/bin) and can be preceded
by PATH=. The default value is PATH=/bin:/usr/bin.

ENV_SUPATH (string)
If set, it will be used to define the PATH environment variable when the superuser login.
The value is a colon separated list of paths (for example /sbin:/bin:/usr/sbin:/usr/bin) and
can be preceded by PATH=. The default value is PATH=/sbin:/bin:/usr/sbin:/usr/bin.

SULOG_FILE (string)
If defined, all su activity is logged to this file.

SU_NAME (string)
If defined, the command name to display when running "su -". For example, if this is defined
as "su" then a "ps" will display the command is "-su". If not defined, then "ps" would
display the name of the shell actually being run, e.g. something like "-sh".

SYSLOG_SU_ENAB (boolean)
Enable "syslog" logging of su activity - in addition to sulog file logging.

FILES
/etc/passwd
User account information.

/etc/shadow
Secure user account information.

/etc/login.defs
Shadow password suite configuration.

EXIT VALUES
On success, su returns the exit value of the command it executed.

If this command was terminated by a signal, su returns the number of this signal plus 128.

If su has to kill the command (because it was asked to terminate, and the command did not
terminate in time), su returns 255.

Some exit values from su are independent from the executed command:

0
success (--help only)

1
System or authentication failure

126
The requested command was not found

127
The requested command could not be executed

SEE ALSO
login(1), login.defs(5), sg(1), sh(1).



shadow-utils 4.1.5.1 02/17/2014 SU(1)

[J G Miller]

On Saturday, October 17th, 2015, at 18:50:17h +0000, Tom McDonald asked:

> Wondering what the difference is between:
> $ su root
> and
> $ su - root

...

> So, in layman's terms, I guess the dash sets the path to what
> I am used to as a normal user.
>
> Is that correct?

No - you have it the wrong way around.

As you are probably aware, when a user logins, various shell
scripts are run which set environmental and possibly shell
specific variables.

When you use su without the dash, you become the other
user (in this case root) but continue using your current
environment (including the PATH environmental variable).

When you use su with the dash, you effectively do a "login"
as that user and get that user (namely root's) environment,
including root's PATH environmental variable, which normally
includes /sbin and /usr/sbin which are not by default present
in that of a user.

So in general, it is better to use su with the dash when using
su to change from one user to another.

[Tom McDonald]

Bit Twister wrote:

> Then again, not using IceWm as Display Environment.
>
> I am used to seeing Xauth type errors.

I don't even know what "IceWm" is.
Searching, I find this comparison of Windows environments, but it's not there:
https://en.wikipedia.org/wiki/Comparison_of_X_Window_System_desktop_environments

I find a description here:
http://www.icewm.org/

It must be the default, because I didn't choose it.

[Tom McDonald]

Bit Twister wrote:

> Where do you feel the node name is being recorded for posterity.
> As for your requirement, you can script a hostname change script and
> call it during shutdown. Next boot would have the new name.

I like the idea of calling it during *shutdown* instead of startup,
as shutdown is less time sensitive, and it will be less prone to
screwing things up. It's a great idea.

BTW, *how* do I best insert a script into a Kubuntu shutdown though?

Searching... is it as simple as calling the script from ~/.bash_logout
or do I modify /sbin/shutdown instead?

[Tom McDonald]

Bit Twister wrote:

> Play around here http://panopticlick.eff.org/ and see for yourself.

I've been there very many times.
I have reduced my fingerprint by a lot, mostly by eliminating fonts.
But there's much more do to.
One by one.

The hostname is what I'm concentrating on at the moment.

[Bit Twister]

On Sat, 17 Oct 2015 18:43:19 +0000 (UTC), Tom McDonald wrote:
> Bit Twister wrote:
>
>> $ grep hosts: /etc/nsswitch.conf
>> hosts: mdns4_minimal files nis dns mdns4 myhostname
>
> What does this file do?

More than a few things. Have you tried man nsswitch.conf

> hosts: files myhostname mdns4_minimal [NOTFOUND=return] dns mdns4

That gives the order that node/ip resolution will be queried.
Check the man page.

[Tom McDonald]

Bit Twister wrote:

> As far as WiFi, your MAC address it better than a node name and is how
> the hotspot knows to route information to your connection.

That's my *next* question.
How to change the mac address upon every reboot.
I don't think that one will work on shutdown (right?).

Here is what I have so far for manually running GNU macchanger:
$ sudo macchanger --random wlan0
Current MAC: 44:8a:5b:8d:3a:0a (Micro-Star INT'L CO., LTD.)
Permanent MAC: 00:24:d7:8d:3a:0a (Intel Corporate)
[ERROR] Could not change MAC: interface up or insufficient permissions: Device or resource busy

# ifconfig wlan0 down
# macchanger --mac 00:00:00:01:02:03 wlan0
# ifconfig wlan0 up
# ifconfig |grep HW|grep wlan0
wlan0 Link encap:Ethernet HWaddr 44:8a:5b:8d:3a:0a

# ifconfig wlan0 down
# macchanger --random wlan0
# macchanger --random wlan0
Current MAC: 44:8a:5b:8d:3a:0a (Micro-Star INT'L CO., LTD.)
Permanent MAC: 00:24:d7:8d:3a:0a (Intel Corporate)
[ERROR] Could not change MAC: interface up or insufficient permissions: Device or resource busy

Does anyone know the working syntax for macchanger?

[Bit Twister]

On Sat, 17 Oct 2015 18:50:17 +0000 (UTC), Tom McDonald wrote:
> Bit Twister wrote:

>> Personally I would use "su - root"
>
> Wondering what the difference is between:
> $ su root
> and
> $ su - root

In a nutshell, entirely possible for files which should be owned by
you will become owned by root. Result, you start having problems that
can only be cleared up by resetting UID:GID to you for all files in
your account.

Here, run the following in order from a terminal.

su

env | sort > /tmp/su.txt
exit

su root
env | sort > /tmp/su_root.txt
exit

su - root
env | sort > /tmp/su_dash_root.txt
exit

env | sort > /tmp/user.txt

diff user.txt /tmp/su.txt
diff user.txt /tmp/su_root.txt
diff user.txt /tmp/su_dash_root.txt

Now, any utility/application using variables in the environment will
cause ownership of those files to belong to the "user" executing the app.

[Bit Twister]

On Sat, 17 Oct 2015 19:00:13 +0000 (UTC), Tom McDonald wrote:
> Bit Twister wrote:
>
>> files in $HOME are owned by
>> root because user did a "su" instead of "su - root" or "su -"
>
> That's not in the manpage for "su" unfortunately, so, I don't
> disbelieve you; it's just not obvious to me.
>
> I'll start using "su -" instead of "su" from now on, but, what
> you know about su must be tribal knowledge because the manpage
> doesn't say it.

Not necessarily tribal knowledge for me. More like knowledge from the
school of hard knocks.

[Bit Twister]

On Sat, 17 Oct 2015 19:13:55 +0000 (UTC), Tom McDonald wrote:
>
> I like the idea of calling it during *shutdown* instead of startup,
> as shutdown is less time sensitive, and it will be less prone to
> screwing things up. It's a great idea.
>
> BTW, *how* do I best insert a script into a Kubuntu shutdown though?
>
> Searching... is it as simple as calling the script from ~/.bash_logout
> or do I modify /sbin/shutdown instead?

1. ~/.bash_logout or ~/.kde*/shutdown/some_script_here have the same problem.
They run with your privileges but modifying hostname requires root privs.

2. I do not recommend modifying system files. Any update can wipe out
your changes.

3. Are you a coder?
$ less /sbin/shutdown
==> This is a dynamic library, showing the output of nm
/sbin/shutdown (END)


My distribution/me modify the PATH environment variable so that the
system admin can place changes in */usr/local/bin to run instead of
the installed *bin files.

Two examples:
$ type -a info
info is /usr/local/bin/info
info is /usr/bin/info
info is /bin/info
info is /local/bin/info

First one found in the above/below is the one that runs.

$ type -a firefox
firefox is /usr/local/bin/firefox
firefox is /usr/bin/firefox
firefox is /bin/firefox


4. Last but not least, depending on release of your distribution:

$ systemctl status systemd-shutdownd.service | grep -i loaded
Loaded: loaded (/usr/lib/systemd/system/systemd-shutdownd.service; static)

$ grep xe /usr/lib/systemd/system/systemd-shutdownd.service
ExecStart=/usr/lib/systemd/systemd-shutdownd

$ less /usr/lib/systemd/systemd-shutdownd
==> This is a dynamic library, showing the output of nm
/usr/lib/systemd/systemd-shutdownd (END)

Having spent some time trying to hook my shutdown script into systemd,
I would appreciate anyone telling me how to hook my script into the
systemd shutdown chain.

[William Unruh]

On 2015-10-17, Tom McDonald <kil...@gmail.com> wrote:

> Bit Twister wrote:
>
>>> Anyway, I'll try dropping down to runlevel 3 with:
>>>
>>> $ su root
>>
>> Personally I would use "su - root"
>
> Wondering what the difference is between:
> $ su root
> and
> $ su - root

The - reinitialises the environment etc (runs .bash_profile I believe)
while without it keeps the same environment the user had. Including
USERNAME, LOGNAME but not HOME.

Try running
env
after trying both.

>
> Here's what the manpage says about the dash:
> "The optional argument - may be used to provide an environment
> similar to what the user would expect had the user logged in
> directly."
>
> Specifically, it seems:
> The value of $PATH is reset to /bin:/usr/bin for normal users,
> or /sbin:/bin:/usr/sbin:/usr/bin for the superuser.

Nope. The value of PATH is what root would have had had root logged in
as root at a login prompt-- this is for su -
for su, the PATH would be whatever the user's path was who ran su

>
> So, in layman's terms, I guess the dash sets the path to what
> I am used to as a normal user.

Nope. the - sets the path t owhat it would have been had you logged in
as root. Without the - it would be the PATH as it was just before su was
run.

>
> Is that correct?
>

[Bit Twister]

On Sat, 17 Oct 2015 19:32:30 +0000 (UTC), Tom McDonald wrote:
> Bit Twister wrote:
>
>> As far as WiFi, your MAC address it better than a node name and is how
>> the hotspot knows to route information to your connection.
>
> That's my *next* question.
> How to change the mac address upon every reboot.
> I don't think that one will work on shutdown (right?).

Depends on how good you are, distribution, and what/which network
manger is being used.

$ edt $(locate /sysconfig.txt)
Ctrl+f macadd
MACADDR=
Set the hardware address for this device to this.
Use of this in conjunction with HWADDR= may cause
unintended behavior.
Quick check in my brain book gives:
$ uh network ubuntu
eth0_ubuntu /etc/NetworkManager/dispatcher.d/01ifupdown
eth0_ubuntu /etc/network/if-up.d, if-down.d, if-pre-up.d, if-post-down.d
debian_ubuntu_uleto_eth0 /etc/network/interfaces man interfaces
ip address loc ubuntu kbuntu /etc/network/interfaces*

[William Unruh]

On 2015-10-17, Tom McDonald <kil...@gmail.com> wrote:

> Bit Twister wrote:
>
>> files in $HOME are owned by
>> root because user did a "su" instead of "su - root" or "su -"
>
> That's not in the manpage for "su" unfortunately, so, I don't
> disbelieve you; it's just not obvious to me.
>
> I'll start using "su -" instead of "su" from now on, but, what
> you know about su must be tribal knowledge because the manpage
> doesn't say it.

Actually the man page DOES say that, you are just misreading it
The format of the su command is
su user
or su - user

When it refers to "user" it means that user listed at the end of the su
command (root if no user is listed.)
Thus the man page says that the environement is what would be usual for
"user" (root by default). NOT the environment which would be normal for
the person who runs su.

..

> -, -l, --login
> Provide an environment similar to what the user would expect had the user logged in
> directly.

user here refers to the last argument of the su funtion, not the person
who run su.

You are confusing "users" and a contrast to "root". It is not. "root"
here is a user just like any other.

[Marek Novotny]

On 2015-10-17, Bit Twister <BitTw...@mouse-potato.com> wrote:

[Unit]
Description=bit.service

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/bin/true
ExecStop=/usr/local/bin/bit.sh

[Install]
WantedBy=graphical.target

adjust the /usr/local/bin/bit.sh which is what I used to test this out.
I have it writing a simple message into a text file in the /tmp
directory. Seems to work fine over here.

[crankypuss]

Marek Novotny wrote:

> On 2015-10-17, crankypuss <inv...@invalid.invalid> wrote:
>> What a pain in the ass. I may be dumber than dog snot, but it seems
>> to me that any system that provides a parameter should also provide a
>> means of setting that parameter which does not include tiptoeing
>> through a parade of kludges.
>
> They are. A distribution is essentially a giant rolling release. The
> kernel is updated ongoing. The shell is updated, less often, but still
> it is. And how it works as a distro is also changed and enhanced
> ongoing. Look at init > upstart > systemd. Look at NetworkManager.
> Before there simply wasn't one. Now there is, and more and more you
> are seeing a text UI for it. And in there you'll be able to change
> your host name. But each distro is unique and follows the ideals of
> its creators. They focus on what they feel is important or maybe it is
> as simple as they had ex amount of time to ex amount of work and they
> are more focused on other things. Eventually they will get to this.

I don't know you much, but I get the definite feeling you've never
worked in a corporate development group and never designed any formal
interfaces; there's an unwritten golden rule to interface dsign,
whenever you expose an interface you do it right because you're going to
be stuck with it for *years*; if it's settable you release the set and
query together, anything else and you end up with exactly the situation
we have right now, which is precisely what one would expect of an ad-hoc
system (and I do not use the term "ad-hoc" in a derogatory way here,
more of the world is ad-hoc than most wish to admit).

> Linux isn't standing still, but it isn't everything you think it
> should be right now, today.

Linux is the kernel, and right now, today, it is more than I need as a
base, for everything I want to do. (I just have to build a lot of code
on top of that base, lol.)

> We have to work on it and guide it. That
> is being done.

Here and there ,by this one and that one, too much by for-profit
corporations to suit my taste, but it is what it is.

> With systemd it's just a command. And with nmtui it is a text ui and
> from it you can set the hostname. Now, kubuntu 14.04 LTS is not up to
> systemd, but later versions are. And I'm not sure which versions, if
> any, support nmtui at this time. On rhel 7, I have both.

Here's my point, again: The fact that installation asks for hostname
and it's used on the network for various things means that it is an
*exposed* interface element; as such it should have both a 'query' and a
'set' (if it is meant to be changable) or it should be *frozen* in place
and have only a 'query'. In every linux distro you've alluded to, that
is not the case. It's one of many things that needs to be fixed, if one
is going to "fix the world" in terms of a "linux distro".

Software evolves over time, and it gets either more complex or less
complex; I favor less complexity.

[crankypuss]

Bit Twister wrote:

> Heheh, and about a month ago, I completed disabling network,
> NetworkManager service and other network apps and moved to using
> systemd-networkd.service. Reduced my boot time by 20 seconds.
> Network restart now works reliably and happens in about a second.

BT, a week or five ago somebody said they had gone to GPT drives and
never looked back, was that you? I'm looking at going that route but
unsure what tools work best with GPT, apparently not my old standby
gparted.

[crankypuss]

Maybe, or maybe it'll just confuse you. Ubuntu 11.10 (oneiric) used
upstart but apparently not systemd. Transitional stuff abounds.

[Marek Novotny]

On 2015-10-17, crankypuss <inv...@invalid.invalid> wrote:

> Bit Twister wrote:
>
>> Heheh, and about a month ago, I completed disabling network,
>> NetworkManager service and other network apps and moved to using
>> systemd-networkd.service. Reduced my boot time by 20 seconds.
>> Network restart now works reliably and happens in about a second.
>
> BT, a week or five ago somebody said they had gone to GPT drives and
> never looked back, was that you? I'm looking at going that route but
> unsure what tools work best with GPT, apparently not my old standby
> gparted.

gdisk, which is very much like fdisk on the command line. You should
start with that. Just throwing in my two cents. I know you asked Bit.

[Marek Novotny]

On 2015-10-17, crankypuss <inv...@invalid.invalid> wrote:

> Tom McDonald wrote:
>
>> Marek Novotny wrote:
>>
>>> Now, kubuntu 14.04 LTS is not up to
>>> systemd, but later versions are. And I'm not sure which versions, if
>>> any, support nmtui at this time.
>>
>> This is good to know for the future.
>
> Maybe, or maybe it'll just confuse you. Ubuntu 11.10 (oneiric) used
> upstart but apparently not systemd. Transitional stuff abounds.

Well, systemd is the future of much of the popular Linux distros. You'd
do well to start learning it soon.

[Bit Twister]

On Sat, 17 Oct 2015 15:20:58 -0600, crankypuss wrote:

Shame on you for highjacking this thread for a completely different agenda.

> Bit Twister wrote:
>
>> Heheh, and about a month ago, I completed disabling network,
>> NetworkManager service and other network apps and moved to using
>> systemd-networkd.service. Reduced my boot time by 20 seconds.
>> Network restart now works reliably and happens in about a second.
>
> BT, a week or five ago somebody said they had gone to GPT drives and
> never looked back, was that you?

Yep, twas me.

> I'm looking at going that route but
> unsure what tools work best with GPT, apparently not my old standby
> gparted.

Hmmm, sounds like an old gparted.

I find it much safer to do partition work completely offline.
Offline in this instance means not running the usual booted OS.
If it is the second drive, I might do it with the running OS.

With any drive you change the disk partition table type, you will
pretty much lose all partitions on that drive.

For offline use I have my rescue cd, either a cd or USB of systemrescuecd-x86
from http://www.sysresccd.org/

When I boot it, I default through everything until last question where
I enter startx (I think) and once the GUI is up, click the gparted
icon at the bottom of screen.

[Bit Twister]

On Sat, 17 Oct 2015 14:32:32 -0700, Marek Novotny wrote:

> gdisk, which is very much like fdisk on the command line. You should
> start with that.

GUI gparted much easier. :-D

[Bit Twister]

On Sat, 17 Oct 2015 14:38:34 -0700, Marek Novotny wrote:

> Well, systemd is the future of much of the popular Linux distros. You'd
> do well to start learning it soon.

Yep, the Borg is well on it's way.

https://en.wikipedia.org/wiki/Systemd#Adoption_and_reception

[Marek Novotny]

I think the HTML5 is changing a lot of that. Especially when we look at
things like iOS and Android apps. It is a burden to get an app through
Apple's authorization all over again. So what we see now are more
dynamic interfaces that can be changed from the service point of view on
the back end.

Look at GoogleDocs and any other web based software. They're not stuck
so much. Features and UI changes are done in the cloud and the users,
using the service-based software have the update within the service.

And in Linux, We see a lot of change as well. Look no further than KDE 4
vs 5 and Gnome 2 vs 3. And in tools for NetworkManager, I watched it
change much in just the last two years and in terms of distribution.
There are also snap-ins to it. Adding OpenVPN for example has a Network
Manager snap in, which alters how the GUI tool presents opens.

>> Linux isn't standing still, but it isn't everything you think it
>> should be right now, today.
>
> Linux is the kernel, and right now, today, it is more than I need as a
> base, for everything I want to do. (I just have to build a lot of code
> on top of that base, lol.)

Yes, Linux is kernel. I'm referring to Linux Distro simply as Linux.

>> We have to work on it and guide it. That
>> is being done.
>
> Here and there ,by this one and that one, too much by for-profit
> corporations to suit my taste, but it is what it is.

Well, I for one welcome it. In fact, I'd like to see a lot more
corporate involvement and adoption of Libre Office next. And I would
very much welcome that with GIMP and Inkwell.

>> With systemd it's just a command. And with nmtui it is a text ui and
>> from it you can set the hostname. Now, kubuntu 14.04 LTS is not up to
>> systemd, but later versions are. And I'm not sure which versions, if
>> any, support nmtui at this time. On rhel 7, I have both.
>
> Here's my point, again: The fact that installation asks for hostname
> and it's used on the network for various things means that it is an
> *exposed* interface element; as such it should have both a 'query' and a
> 'set' (if it is meant to be changable) or it should be *frozen* in place
> and have only a 'query'. In every linux distro you've alluded to, that
> is not the case. It's one of many things that needs to be fixed, if one
> is going to "fix the world" in terms of a "linux distro".

Not every distro asks for a hostname or even asks in the same way. And
they don't store the info in the same way. Try running hostname -f on
OpenSuse and then try that on Ubuntu. Try it on rhel. Personally, I
think rhel nails the installation. And if we're talking v7.x as I said,

You can query, with hostname. You can set, with systemd with a single
command line entry.

> Software evolves over time, and it gets either more complex or less
> complex; I favor less complexity.

Well, you have to start somewhere. As I said, we're getting there.

[Marek Novotny]

On 2015-10-17, Bit Twister <BitTw...@mouse-potato.com> wrote:

If you have a GUI.... :p

[Bit Twister]

Hehe, I wonder how that really worked. Usually /tmp is just a piece of
memory and your /tmp/some_file_here would not be there on a new boot.

The problem is I need to shutdown some services which can hang the
shutdown process. Example while testing your methodology, systemd hung
counting down named for 1 minute and 30 seconds. I powered off just to
get past that and others which bog down shutdown unless I get them
stopped before systemd starts the shutdown process.

Keep in mind systemd is running shutdown process in parallel and as a
result those other services I needed shutdown have already started
shutdown thus trapping my service causing even more delay. :(

[Marek Novotny]

Maybe raise the issue here:

http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Yeah, don't know how to do that inside systemd. Unless you just want to
execute your own script and then have that call for the shutdown.

[Chris Ahlstrom]

Bit Twister wrote this copyrighted missive and expects royalties:

Right now, for me, the benefits slightly outweight the problems.

Signed,

Dover, Ben

--
Break into jail and claim police brutality.

[Bit Twister]

On Sat, 17 Oct 2015 19:26:59 -0400, Chris Ahlstrom wrote:
> Bit Twister wrote this copyrighted missive and expects royalties:
>
>> On Sat, 17 Oct 2015 14:38:34 -0700, Marek Novotny wrote:
>>
>>> Well, systemd is the future of much of the popular Linux distros. You'd
>>> do well to start learning it soon.
>>
>> Yep, the Borg is well on it's way.
>>
>> https://en.wikipedia.org/wiki/Systemd#Adoption_and_reception
>
> Right now, for me, the benefits slightly outweight the problems.

Other than the occasional service hanging the system, it has been
pretty uneventful other than knowing how to get my shutdown script
running at the right time automagically.

It is not a real problem since for the most part my new_boot_logs
script has no problems shutting down services prior to calling reboot.

Took a few days for me to convert pulse audio to a system server instead
of a user service and set default output devices and volume levels.

That enables cron and my at jobs to play audio files.

[Tom McDonald]

Bit Twister wrote:

> Here, run the following in order from a terminal.

Yikes!
The results are VERY different!
I'm not sure what corrective actions to take, but, I easily
see that the suggested commands provide different results!
--------------------------------------------------

su
env | sort > /tmp/su.txt
exit
su root
env | sort > /tmp/su_root.txt
exit
su - root
env | sort > /tmp/su_dash_root.txt
exit
env | sort > /tmp/user.txt

--------------------------------------------------
$ diff user.txt /tmp/su.txt
--------------------------------------------------
17c17
< HOME=/home/tom
---
> HOME=/root
29,30c29,30
< LANG=en_DE.UTF-8
< LANGUAGE=en
---
> LANG=en_US.UTF-8
> LANGUAGE=en_CA:en
44c44
< LOGNAME=tom
---
> LOGNAME=root
45a46
> MAIL=/var/mail/root
61c62
< SHLVL=1
---
> SHLVL=2
70c71
< USER=tom
---
> USER=root
82a84
> XDG_SESSION_COOKIE=8689cc6dddbc43eaf845a16752654609-4847238768.81397-27667353
--------------------------------------------------
$ diff user.txt /tmp/su_root.txt
--------------------------------------------------
17c17
< HOME=/home/tom
---
> HOME=/root
29,30c29,30
< LANG=en_DE.UTF-8
< LANGUAGE=en
---
> LANG=en_US.UTF-8
> LANGUAGE=en_CA:en
44c44
< LOGNAME=tom
---
> LOGNAME=root
45a46
> MAIL=/var/mail/root
61c62
< SHLVL=1
---
> SHLVL=2
70c71
< USER=tom
---
> USER=root
82a84
> XDG_SESSION_COOKIE=8689cc6dddbc43eaf845a16752654609-4847238783.861315-456262993
--------------------------------------------------
$ diff user.txt /tmp/su_dash_root.txt
--------------------------------------------------
1,5d0
< CLUTTER_IM_MODULE=xim
< COLORFGBG=15;0
< DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-PDf3v3u1f8
< DEFAULTS_PATH=/usr/share/gconf/kde-plasma.default.path
< DESKTOP_SESSION=kde-plasma
7,31c2,4
< GDM_LANG=en_CA
< GDMSESSION=kde-plasma
< GNOME_KEYRING_CONTROL=/run/user/1000/keyring-wlz0vl
< GNOME_KEYRING_PID=2083
< GPG_AGENT_INFO=/tmp/gpg-W69LQ6/S.gpg-agent:2319:1
< GS_LIB=/home/tom/.fonts
< GTK2_RC_FILES=/etc/gtk-2.0/gtkrc:/home/tom/.gtkrc-2.0:/home/tom/.kde/share/config/gtkrc-2.0
< GTK_IM_MODULE=ibus
< GTK_MODULES=overlay-scrollbar
< GTK_RC_FILES=/etc/gtk/gtkrc:/home/tom/.gtkrc:/home/tom/.kde/share/config/gtkrc
< HOME=/home/tom
< IM_CONFIG_PHASE=1
< INSTANCE=
< JOB=dbus
< KDE_FULL_SESSION=true
< KDE_MULTIHEAD=false
< KDE_SESSION_UID=1000
< KDE_SESSION_VERSION=4
< KONSOLE_DBUS_SERVICE=:1.222
< KONSOLE_DBUS_SESSION=/Sessions/1
< KONSOLE_DBUS_WINDOW=/Windows/1
< KONSOLE_PROFILE_NAME=Shell
< LANG=en_DE.UTF-8
< LANGUAGE=en
< LC_ADDRESS=en_DE.UTF-8
---
> HOME=/root
> LANG=en_US.UTF-8
> LANGUAGE=en_CA:en
33,40d5
< LC_IDENTIFICATION=en_DE.UTF-8
< LC_MEASUREMENT=en_DE.UTF-8
< LC_MONETARY=en_DE.UTF-8
< LC_NAME=en_DE.UTF-8
< LC_NUMERIC=en_DE.UTF-8
< LC_PAPER=en_DE.UTF-8
< LC_TELEPHONE=en_DE.UTF-8
< LC_TIME=en_DE.UTF-8
43,44c8
< LIBOVERLAY_SCROLLBAR=0
< LOGNAME=tom
---
> LOGNAME=root
46,53c10,12
< MANDATORY_PATH=/usr/share/gconf/kde-plasma.mandatory.path
< PAM_KWALLET_LOGIN=/tmp//tom.socket
< PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
< PROFILEHOME=/tmp
< PWD=/tmp
< QT4_IM_MODULE=ibus
< QT_IM_MODULE=ibus
< QT_PLUGIN_PATH=/home/tom/.kde/lib/kde4/plugins/:/usr/lib/kde4/plugins/
---
> MAIL=/var/mail/root
> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
> PWD=/root
55,58d13
< SELINUX_INIT=YES
< SESSION=kde-plasma
< SESSION_MANAGER=local/old:@/tmp/.ICE-unix/2511,unix/old:/tmp/.ICE-unix/2511
< SESSIONTYPE=
60d14
< SHELL_SESSION_ID=897f376bc1fc4000946332fe865b59a4
62d15
< SSH_AUTH_SOCK=/run/user/1000/keyring-wlz0vl/ssh
64,70c17
< TEXTDOMAINDIR=/usr/share/locale/
< TEXTDOMAIN=im-config
< UPSTART_EVENTS=started xsession
< UPSTART_INSTANCE=
< UPSTART_JOB=startkde
< UPSTART_SESSION=unix:abstract=/com/ubuntu/upstart-session/1000/2092
< USER=tom
---
> USER=root
72d18
< WINDOWID=201843098
74,81d19
< XCURSOR_SIZE=48
< XCURSOR_THEME=redglass
< XDG_CONFIG_DIRS=/etc/xdg/xdg-kde-plasma:/usr/share/upstart/xdg:/etc/xdg
< XDG_CURRENT_DESKTOP=KDE
< XDG_DATA_DIRS=/usr/share:/usr/share/kde-plasma:/usr/local/share/:/usr/share/
< XDG_GREETER_DATA_DIR=/var/lib/lightdm-data/tom
< XDG_RUNTIME_DIR=/run/user/1000
< XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
82a21
> XDG_SESSION_COOKIE=8689cc6dddbc43eaf845a16752654609-4847238803.673834-882401301
84d22
< XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0
86d23
< XMODIFIERS=@im=ibus
--------------------------------------------------

[Tom McDonald]

Bit Twister wrote:

> Depends on how good you are, distribution, and what/which network
> manger is being used.
>
> $ edt $(locate /sysconfig.txt)

There is no sysconfig on Kubuntu 14.04 but ifconfig (or
macchanger), you would think, *should* set the NIC MAC.

This tells us the current MAC for the wireless NIC:
$ alias whichmac='ifconfig|grep HW|grep wlan0'
$ whichmac
=> wlan0 Link encap:Ethernet HWaddr 00:01:02:03:04:05

This *should* reset the MAC:
$ sudo ifconfig wlan0 down
$ sudo ifconfig wlan0 hw ether 00:00:00:11:11:11
$ sudo ifconfig wlan0 up

This should also reset the MAC:
$ sudo ifconfig wlan0 down
$ sudo macchanger -m 00:00:00:11:11:11 wlan0
$ sudo ifconfig wlan0 up

Putting it together, this *should* work, but fails:
$ alias newmac='ifconfig wlan0|grep HW;sudo ifconfig wlan0 down;sudo macchanger -A;sudo ifconfig wlan0 up;ifconfig wlan0|grep HW'
$ newmac
=> wlan0 Link encap:Ethernet HWaddr 00:01:02:03:04:05
=> GNU MAC Changer
=> Usage: macchanger [options] device
=> Try `macchanger --help' for more options.
=> wlan0 Link encap:Ethernet HWaddr 00:01:02:03:04:05

[Tom McDonald]

Bit Twister wrote:

> 1. ~/.bash_logout or ~/.kde*/shutdown/some_script_here have the same problem.
> They run with your privileges but modifying hostname requires root privs.

I had not known about the kde shudown directory before. Mine is empty.

My bash logout is at the default:

$ cat .bash_logout
# ~/.bash_logout: executed by bash(1) when login shell exits.

# when leaving the console clear the screen to increase privacy

if [ "$SHLVL" = 1 ]; then
[ -x /usr/bin/clear_console ] && /usr/bin/clear_console -q
fi

Maybe I can add the hostname commands to sudoers.d so that the normal
user can change the hostname upon shutdown?

[Tom McDonald]

Bit Twister wrote:

>
> 3. Are you a coder?
> $ less /sbin/shutdown

The /sbin/shutdown file is a binary file on Kubuntu 14.04; however,
a "locate" command locates a few potential shutdown conf files:

$ locate shutdown
/etc/init/plymouth-shutdown.conf
/etc/init/shutdown.conf
/sbin/shutdown
/usr/bin/kdeinit4_shutdown
etc.

[Tom McDonald]

William Unruh wrote:

> Thus the man page says that the environement is what would be usual for
> "user" (root by default). NOT the environment which would be normal for
> the person who runs su.

Thanks for explaining. I misinterpreted the manpage.
The correction is much appreciated.

[Bit Twister]

On Sun, 18 Oct 2015 02:12:06 +0000 (UTC), Tom McDonald wrote:
> Bit Twister wrote:
>
>> Depends on how good you are, distribution, and what/which network
>> manger is being used.
>>
>> $ edt $(locate /sysconfig.txt)
>
> There is no sysconfig on Kubuntu 14.04

That is not a display environment file. It is a distribution specific file.

> but ifconfig (or
> macchanger), you would think, *should* set the NIC MAC.

You are using command line activities to modify a running interface.
What you are needing to do is set the value before the connected is started.

Did you even try the suggested man page. :(

[Bit Twister]

On Sun, 18 Oct 2015 02:16:27 +0000 (UTC), Tom McDonald wrote:
> Bit Twister wrote:
>
>> 1. ~/.bash_logout or ~/.kde*/shutdown/some_script_here have the same problem.
>> They run with your privileges but modifying hostname requires root privs.
>
> I had not known about the kde shudown directory before. Mine is empty.

Yup, I use it clean out the trash and kill user process that seem to
hang around after logout.

> Maybe I can add the hostname commands to sudoers.d so that the normal
> user can change the hostname upon shutdown?

That should work, hopefully making the change as late as possible in
the shutdown process to prevent problems.

I wish you luck, but have you considered what your new "ramdom" FQDN
is going to look like????

[Bit Twister]

On Sun, 18 Oct 2015 02:18:57 +0000 (UTC), Tom McDonald wrote:
> Bit Twister wrote:
>
>>
>> 3. Are you a coder?
>> $ less /sbin/shutdown
>
> The /sbin/shutdown file is a binary file on Kubuntu 14.04; however,

And as I tried to show you, systemd does not use/shutdown but runs a
systemd app to do the shutdown.

Yes you might not be running systemd now but guessing your next ?buntu
release will.

[Tom McDonald]

Bit Twister wrote:

> I wish you luck, but have you considered what your new "ramdom" FQDN
> is going to look like????

I never understood this fully qualified domain name because even a
"hostname -f" outputs the *same* info as "hostname" without the -f.

$ hostname
=> old

$ hostname -f
=> old

-f, --fqdn, --long
Display the FQDN (Fully Qualified Domain Name). A FQDN consists of a short host name and
the DNS domain name. Unless you are using bind or NIS for host lookups you can change the
FQDN and the DNS domain name (which is part of the FQDN) in the /etc/hosts file. See the
warnings in section THE FQDN above und use hostname --all-fqdns instead wherever possi‐
ble.

So the FQDN and the hostname are exactly the same thing anyway.

[Marek Novotny]

No, and this is part of the reason I don't much care for the hostname
command in the first place. Some distros just seem to want a simple
name, like ws1. rhel wants a FQDN, like ws1.marspolar.com.

When you have a FQDN like ws1.marspolar.com and your hostname command
supports the arguments of -s for short and -f for full, you'll get two
different outputs.

-s will yield ws1
-f will yield ws1.marspolar.com

If you change your hostname to a FQDN and then use those arguments on
your Kubuntu release, you'll see this.

[Tom McDonald]

Bit Twister wrote:

> You are using command line activities to modify a running interface.
> What you are needing to do is set the value before the connected is started.

I agree that it's a running interface.
But there must be a way to change the MAC address.
I thought stopping the interface from the command line would work.
But it failed.

> Did you even try the suggested man page

I didn't know there was a suggested manpage.
For what?

Looking back, this was your last post (and the one I had responded to).
Is there a suggested manpage in that?
I couldn't understand almost any of it.
(Sorry).

---- this is the last post ----almost none of which I understood -----

Depends on how good you are, distribution, and what/which network
manger is being used.

$ edt $(locate /sysconfig.txt)

Ctrl+f macadd
MACADDR=
Set the hardware address for this device to this.
Use of this in conjunction with HWADDR= may cause
unintended behavior.
Quick check in my brain book gives:
$ uh network ubuntu
eth0_ubuntu /etc/NetworkManager/dispatcher.d/01ifupdown
eth0_ubuntu /etc/network/if-up.d, if-down.d, if-pre-up.d, if-post-down.d
debian_ubuntu_uleto_eth0 /etc/network/interfaces man interfaces
ip address loc ubuntu kbuntu /etc/network/interfaces*

[Tom McDonald]

Marek Novotny wrote:

> -s will yield ws1
> -f will yield ws1.marspolar.com
>
> If you change your hostname to a FQDN and then use those arguments on
> your Kubuntu release, you'll see this.

I just ran both commands, and, as you noted, they come out the same:
$ hostname -s

=> old
$ hostname -f
=> old

Then, I tried to change the /etc/hosts line from:
127.0.1.1 old
to a FQDN - but - um - *what* FQDN do I use?
127.0.1.1 old.foo.com ???

I have absolutely no idea what FQDN my ISP would be using.
How do I even figure that out?

[Marek Novotny]

On 2015-10-18, Tom McDonald <kil...@gmail.com> wrote:

I borrowed much of this from the web, not really too interested in
writing this one myself. So I found one and modified it a bit. I have
difficulty testing it on my Kubuntu VM though. So you could try this on
your own hardware and if you get any grief, just reboot and it should
all go away.

#!/bin/bash

if [ $(id -u) != 0 ] ; then
priv="sudo"
else
priv=""
fi

# grab the interface
devID=$(ip route get 8.8.8.8 | awk 'NR==1 {print $5}')
MACaddr=$(ifconfig $devID | grep HWaddr | awk '{print $5}')

echo "old MAC: $MACaddr"

# get the OUI from a list of legit OUIs
OUIArray=(
00:1c:bf # intel
00:12:f0 # intel
00:1b:e9 # broadcom
18:c0:86 # broadcom
d4:ae:52 # dell
d4:be:d9 # dell
00:1d:09 # dell
d4:c9:ef # hp
d8:9d:67 # hp
d8:9e:3f # apple
d8:a2:5e # apple
)

RANGE=$((${#OUIArray[@]} + 1))
i=$RANDOM
let "i %= $RANGE"
OUI=${OUIArray[$i]}

# generate a new NIC specific identifier
NIC=$(date | md5sum | sed 's/../&:/g' | cut -b 9-17)
newMAC="$OUI$NIC"

echo "new MAC: $newMAC"

# Offer to replace old mac addr with the new
echo "Do you wish to assign $newMAC to $devID?"
select yn in "Yes" "No" ; do
case $yn in
Yes )
$priv ifconfig $devID down
sleep 2 # allow interface to go down
$priv ifconfig $devID hw ether $newMAC
sleep 2 # allow time to assign MAC to interface
$priv ifconfig $devID up && $priv ifconfig $devID | grep HWaddr
break
;;
No )
exit 0
;;
esac
done

## END ##

[Tom McDonald]

Tom McDonald wrote:

> I have absolutely no idea what FQDN my ISP would be using.
> How do I even figure that out?

I just figured out, by googling, that "nslookup" combined with
"curl" will do the trick, I think.

$ curl http://myip.dnsomatic.com
=> 1.2.3.4

$ nslookup 1.2.3.4
=> Gives me my FQDN (I think)

[Marek Novotny]

On 2015-10-18, Tom McDonald <kil...@gmail.com> wrote:

If you go into my repos, grab linfo, and run it. It will show you much
of your network and how the world sees you. It's a longer script,
roughly 650 lines, but it meant to help people learn how to dig up this
kind of info. I tried to make it straight forward and not require an
privilege to run it.

This question is actually one of the good questions that helps to
explain why learning to script is a good idea. To get the answer you
need you need to compound a few things from your system.

You need to know your own outside IP address, and then you'll need to do
a reverse lookup on that external address.

So like this: dig +short -x $(wget -4 -qO- icanhazip.com)

Give that a try... But for myself I am my own domain. So I use my own
domain in my machine names.

[Tom McDonald]

Marek Novotny wrote:

> So you could try this on
> your own hardware and if you get any grief, just reboot

Here is the first that I will try in a minute & report back.

#!/bin/bash
#################################################
#
# Script: macaddr.sh
# written by: Marek Novotny
# version: 0.1
# Date: 2015-10-17
# Notes: MAC Address Changing Kubuntu
#
#################################################

[Tom McDonald]

Marek Novotny wrote:

> You need to know your own outside IP address, and then you'll need to do
> a reverse lookup on that external address.
>
> So like this: dig +short -x $(wget -4 -qO- icanhazip.com)

That gave the following result:
$ dig +short -x $(wget -4 -qO- icanhazip.com)
=> ool-45703fed.dyn.optonline.net.

I then used your ntest.sh script; but it needs nm-tool
(I'm using wicd because it's tons more reliable).

$ ntest.sh
/usr/local/bin/ntest.sh: line 26: nm-tool: command not found
grep: 10.211.1.17: No such file or directory
/usr/local/bin/ntest.sh: line 27: nm-tool: command not found
grep: 10.211.1.17: No such file or directory
Ping testing:
==========================================================================================================
Assigned IP: 192.168.1.30
10.211.1.17 (Fail)
Gateway: (Fail)

Website testing:
==========================================================================================================
www.yahoo.com (Pass)
www.google.com (Pass)
www.redhat.com (Pass)
www.ubuntu.com (Pass)

/usr/local/bin/ntest.sh: line 82: nm-tool: command not found
grep: 10.211.1.17: No such file or directory
Invalid option: -x
Usage: dig [@global-server] [domain] [q-type] [q-class] {q-opt}
{global-d-opt} host [@local-server] {local-d-opt}
[ host [@local-server] {local-d-opt} [...]]

Use "dig -h" (or "dig -h | more") for complete list of options
External Network Info:
==========================================================================================================
Hostname: old
ExternalIP: 69.112.63.237
Reverse Lookup: ool-45703fed.dyn.optonline.net.
DNS:
DNS Name:
ISP: AS6128 Cablevision Systems Corp.


Here is the program I used for that information above:
#!/bin/bash
#################################################
#
# Script: ntest.sh

# written by: Marek Novotny

# Contributors: Jonathan N. Little
# Contributors: Mike Easter
# version: 1.1
# Date: 2014-12-08
#
# Notes: Tests network connectivity
#
#################################################

dashLines() {
printf "%*s\n" "${COLUMNS:-$(tput cols)}" '' | tr ' ' =
}

insideNetwork() {
clear
IFS=$'\r\n'
assignedIP=$(ip addr | grep -vi loopback | grep -v 127 \
| grep -v inet6 | grep -v vir | grep inet | awk '{print $2}' \
| cut -d'/' -f1)
gatewayIP=$(nm-tool | grep $assignedIP -A 3 | grep -i gateway \
| awk '{print $2}')
DNS=$(nm-tool | grep $assignedIP -A 5 | grep DNS | awk '{print $2}')

printf "%s\n" "Ping testing:"
dashLines
printf "%s" " Assigned IP: $assignedIP"; addr=$assignedIP; pt
printf "%s" " Gateway: $gatewayIP"; addr=$gatewayIP; pt
for i in ${DNS[@]}; do
printf "%s" " DNS: $i"; nt
done
echo ""
webTest
}

pt() {
(ping -c 1 ${addr}) > /dev/null 2>&1 \
&& printf "%s\n" " (Pass)" \
|| printf "%s\n" " (Fail)"
}

nt() {
(nc -nv -w 3 ${i} 53) > /dev/null 2>&1 \
&& printf "%s\n" " (Pass)" \
|| printf "%s\n" " (Fail)"
}

webTest() {
printf "%s\n" "Website testing:"
dashLines
count=0
sites=("www.yahoo.com" "www.google.com" "www.redhat.com" "www.ubuntu.com")

for ix in ${sites[@]}; do
wget -q -t1 -T5 --spider $ix && wp || wf
done
echo ""
if ((count >= 1)); then
outsideNetwork
fi
}

wp() {
((count++))
printf "\t%s\t%s\t\n" "$ix" "(Pass)"
}

wf() {
printf "\t%s\t%s\t\n" "$ix" "(Fail)"
}

outsideNetwork() {
FQD=$(hostname -f)
DomainName=$(dnsdomainname)
DomainIP=$(dig +short $DomainName | head -n1)
ExternalIP=$(wget -qO- icanhazip.com)
ReverseLookup=$(dig +short -x $ExternalIP)
DNSIP=$(nm-tool | grep $assignedIP -A 4 | grep DNS | awk '{print $2}')
DNSName=$(dig +short -x $DNSIP)
ISP=$(wget -qO- ipinfo.io/$ExternalIP/org)

printf "%s\n" "External Network Info:"
dashLines
printf "%s\n" " Hostname: $FQD"
printf "%s\n" " ExternalIP: $ExternalIP"
printf "%s\n" " Reverse Lookup: $ReverseLookup"
printf "%s\n" " DNS: $DNSIP"
printf "%s\n" " DNS Name: $DNSName"
printf "%s\n" " ISP: $ISP"
echo ""
}

ip addr | grep "state UP" > /dev/null 2>&1 \
&& insideNetwork \
|| printf "\n%s\n\n" "Error! No Valid IP address..."

[Tom McDonald]

Marek Novotny wrote:

> If you go into my repos, grab linfo, and run it. It will show you much
> of your network and how the world sees you.

Got it:
https://raw.githubusercontent.com/marek-novotny/linfo/master/linfo.sh

Running it in a second...

[Tom McDonald]

Tom McDonald wrote:

> Got it:
> https://raw.githubusercontent.com/marek-novotny/linfo/master/linfo.sh
>
> Running it in a second...

Interesting. Very interesting results.
For example...

$ linfo.sh > /tmp/foo
$ more /tmp/foo
Hostname: old
Full Name: tom,,,
User Name: tom
User ID: 1000
Group: adm:4
...
Linux Kernel Taint Status Description
1 - A module with a non-GPL license has been loaded, which
includes modules with no license set by modutils >= 2.4.9 and
module-init-tools.
4096 - An out-of-tree module has been loaded.
8192 - An unsigned module has been loaded in a kernel supporting module
signature.
...

ISP: AS6128 Cablevision Systems Corp.

External IP: 69.112.63.237
Reverse Lookup: ool-45703fed.dyn.optonline.net.
Hostname: old
Domain Name: ool-45703fed.dyn.optonline.net.
HOST + rDNS: old.ool-45703fed.dyn.optonline.net.
Name Server: None Detected
Mail Exchange: None Detected
DNS: 192.168.1.1
DNS Name: None Detected

...

[Tom McDonald]

Tom McDonald wrote:

> Here is the first that I will try in a minute & report back.
>
> #!/bin/bash
> #################################################
> #
> # Script: macaddr.sh

It did strange things, but, some seemed to work, so, there is
much promise here, since it didn't need to be root (it seems).

At first, it triggered Marek's "vpnstatus.sh" command, which
killed my vpn session but then, off of vpn, it seemed to work
the first time, but not the second time.

I realize those are screwy results, so, I'll just cut and paste
here and try again to figure out what it's doing.

1. FIRST TEST (note that I was on VPN at the time & vpnstatus.sh
was triggered to kill everything when I ran macaddr.sh)

$ macaddr.sh
old MAC: 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
new MAC: d8:a2:5e:68:35:de
Do you wish to assign d8:a2:5e:68:35:de to tun0?
1) Yes
2) No
#? Yes
#? 1
SIOCSIFHWADDR: Operation not supported
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00

2. SECOND TEST (now that vpnstatus.sh triggered, I was off VPN):
$ macaddr.sh
old MAC: 00:a0:00:a3:23:01
new MAC: d4:c9:ef:8f:e8:ef
Do you wish to assign d4:c9:ef:8f:e8:ef to wlan0?
1) Yes
2) No
#? 1
wlan0 Link encap:Ethernet HWaddr d4:c9:ef:8f:e8:ef

$ ifconfig|grep 'wlan0'|tr -s ' '|cut -d ' ' -f5
=> d4:c9:ef:8f:e8:ef

3. THIRD TEST (for some reason, running it a second time failed):
$ macaddr.sh
old MAC: 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
new MAC: 00:1d:09:fc:65:ee
Do you wish to assign 00:1d:09:fc:65:ee to tun0?
1) Yes
2) No
#? 1
SIOCSIFHWADDR: Operation not supported
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00

$ ifconfig|grep 'wlan0'|tr -s ' '|cut -d ' ' -f5
d4:c9:ef:8f:e8:ef

[Bit Twister]

What you see/saw is keywords used for searching my unix.help file,
followed by some kind of information, a directory, command, or the
start of a bread crumb trail to more information.

If you bother to look closely you might see the man some_item_here.
If you were to read that man page you might see where you can set a
hardware address.

[Bit Twister]

On Sun, 18 Oct 2015 04:27:30 +0000 (UTC), Tom McDonald wrote:
> Marek Novotny wrote:
>
>> -s will yield ws1
>> -f will yield ws1.marspolar.com
>>
>> If you change your hostname to a FQDN and then use those arguments on
>> your Kubuntu release, you'll see this.
>
> I just ran both commands, and, as you noted, they come out the same:
> $ hostname -s
> => old
> $ hostname -f
> => old

If they do, you did not set a FQDN for your node.

> Then, I tried to change the /etc/hosts line from:
> 127.0.1.1 old
> to a FQDN - but - um - *what* FQDN do I use?
> 127.0.1.1 old.foo.com ???

In your example, old.foo.com is the FQDN and ??? is the alias/short name.

So using the above the line would/should be
127.0.1.1 old.foo.com old

I would not recommend the foo.com domain. Why you ask?

$ nslookup foo.com
Server: 127.0.0.1
Address: 127.0.0.1#53

Non-authoritative answer:
Name: foo.com
Address: 23.21.224.150
Name: foo.com
Address: 23.21.179.138

Even though you can not find anyone using a domain name, it does not
mean, it will be sold sometime in the future.

You might want to read http://www.rfc-editor.org/rfc/rfc2606.txt

As for hostname:
$ hostname -s
wb

$ hostname -f
wb.home.test

$ hostname
wb.home.test

[Marek Novotny]

On 2015-10-18, Tom McDonald <kil...@gmail.com> wrote:

I never even thought about running from the tunnel. Don't think you need
to either. Nor do I think you'd need to run this with TOR. If you did,
you'd run this first, then go VPN.

[Bit Twister]

On Sat, 17 Oct 2015 22:32:50 -0700, Marek Novotny wrote:

> I never even thought about running from the tunnel. Don't think you need
> to either. Nor do I think you'd need to run this with TOR. If you did,
> you'd run this first, then go VPN.

Hehe, careful of line wrap.

http://arstechnica.com/security/2015/10/how-the-nsa-can-break-trillions-of-encrypted-web-and-vpn-connections/

[Marek Novotny]

:(

I posted about the diffie-hellman yesterday in that PDF I posted.

https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf

Pretty scary stuff, but at least a fire has been lit under everyone's
butts as a result.

[Tom McDonald]

Marek Novotny wrote:

> I never even thought about running from the tunnel. Don't think you need
> to either. Nor do I think you'd need to run this with TOR. If you did,
> you'd run this first, then go VPN.

Yup. Marek. That makes sense. I just did that, and it works when I am
not on VPN, but it fails when I'm on VPN (which is ok).

This is great because I don't have to be root.
I don't yet understand *how* it did that, but I'll look deeper at
the macaddr.sh script to figure that out.

Here is the result of the first test off and on VPN.

WHEN NOT ON VPN:

$ ifconfig|grep 'wlan0'|tr -s ' '|cut -d ' ' -f5

=> 00:12:f0:44:f8:c5

$ macaddr.sh
old MAC: 00:12:f0:44:f8:c5
new MAC: d8:9d:67:56:82:c1
Do you wish to assign d8:9d:67:56:82:c1 to wlan0?

1) Yes
2) No
#? 1

wlan0 Link encap:Ethernet HWaddr d8:9d:67:56:82:c1

$ ifconfig|grep 'wlan0'|tr -s ' '|cut -d ' ' -f5

=> d8:9d:67:56:82:c1

WHEN ON VPN:

$ macaddr.sh
old MAC: 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00

new MAC: 00:1b:e9:2b:1b:2b
Do you wish to assign 00:1b:e9:2b:1b:2b to tun0?

[Tom McDonald]

Bit Twister wrote:

> If you bother to look closely you might see the man some_item_here.
> If you were to read that man page you might see where you can set a
> hardware address.

I think we have a potential winner with Marek's macaddr.sh script,
which works, it seems, without needing to be root.

One problem I'm having is syntactically getting this alias though:

$ ifconfig|grep 'wlan0'|tr -s ' '|cut -d ' ' -f5

Normally, in my bash_aliases file I would just put single quotes:
alias whatmac='ifconfig|grep 'wlan0'|tr -s ' '|cut -d ' ' -f5'

But that fails every time.
Is there something that will "protect" the first & last single quote?

[Bit Twister]

On Sun, 18 Oct 2015 05:55:25 +0000 (UTC), Tom McDonald wrote:
>
> I think we have a potential winner with Marek's macaddr.sh script,
> which works, it seems, without needing to be root.

Me thinks you are playing with a connection which is already established.

> Normally, in my bash_aliases file I would just put single quotes:
> alias whatmac='ifconfig|grep 'wlan0'|tr -s ' '|cut -d ' ' -f5'
>
> But that fails every time.
> Is there something that will "protect" the first & last single quote?

Have you tried

alias whatmac="ifconfig|grep 'wlan0'|tr -s ' '|cut -d ' ' -f5"

In the event you need to protect some character you might consider
escaping it with a back slash.

Do run the above and run the command
alias whatmac

I would suggest that ifconfig is on its way out, and can have
different field position for data on different distribution and might
change in a new release.

On the other hand, "id" might be the better command. Example:

$ set -- $(ip -o link show enp3s0) ; echo ${17}
a0:f3:c1:00:3c:1e

What is the above you ask,
$ ifconfig enp3s0
enp3s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.11.132 netmask 255.255.255.0 broadcast 192.168.11.255
ether a0:f3:c1:00:3c:1e txqueuelen 1000 (Ethernet)

[Tom McDonald]

Bit Twister wrote:

> Have you tried
> alias whatmac="ifconfig|grep 'wlan0'|tr -s ' '|cut -d ' ' -f5"
>
> In the event you need to protect some character you might consider
> escaping it with a back slash.
>
> Do run the above and run the command
> alias whatmac

That worked perfectly!
thanks.

I thought I had tried doublequotes and backslashing the single quote.
Maybe I did it wrong, because the doublequote worked as shown below:

[Tom McDonald]

Bit Twister wrote:

> What is the above you ask,

$ set -- $(ip -o link show enp3s0) ; echo ${17}

=> Device "enp3s0" does not exist.

$ ifconfig enp3s0
=> enp3s0: error fetching interface information: Device not found

What is "enp3s0" I ask?

[Tom McDonald]

J.O. Aho wrote:

>> 2. Is there an existing script to change hostnames more easily?
>
> with little bash skills you can write your own.

It's f' ugly, but here is my first pass.
It seems to work, even though I'm using wicd so the network stays up
the entire time.

Of course, any and all suggestions will be considered, because it's really
embarrassingly written code.

#!/bin/bash
#################################################
#
# Script: changehostname.sh
# written by: Tom McDonald
# Contributors : Marek Novotny, Bit Twister

# version: 0.1
# Date: 2015-10-17

# Notes: Change hostname on Kubuntu
#
#################################################
OLD_HOST=$(hostname)

if [ $# -eq 0 ]
then
echo "OLD_HOST=$(hostname)"
echo -n "Enter New Hostname: "
read NEW_HOST
else
NEW_HOST=$1
fi

if [ $(id -u) != 0 ] ; then
priv="sudo"
else
priv=""
fi

# $priv service network-manager stop
$priv cp /etc/hostname /etc/hostname.bkup
# $priv sed "s/127.0.0.1 ${OLD_HOST}\$/127.0.0.1 ${NEW_HOST}\$/ /etc/hostname.bkup > /etc/hostname
$priv vi /etc/hostname
$priv cp /etc/hosts /etc/hosts.bkup
$priv vi /etc/hosts
$priv hostname $NEW_HOST
echo "Changed ${OLD_HOST} to ${NEW_HOST}"
$priv chmod 777 /etc/sudoers.d/vpn-ifconfig
$priv echo "$(whoami) $(hostname) = (root) NOPASSWD: $(type -p ifconfig)" >> /etc/sudoers.d/vpn-ifconfig
$priv vi /etc/sudoers.d/vpn-ifconfig
$priv chmod 0440 /etc/sudoers.d/vpn-ifconfig
hostname -f

# I may need to change this next command to wicd's command to restart the network:
# $priv service network-manager restart

echo "Blowing away kde {cache,socket,tmp}-$OLD_HOST"
$priv rm -rf /home/`whoami`/.kde/cache-$OLD_HOST
$priv rm -rf /home/`whoami`/.kde/tmp-$OLD_HOST
$priv rm -rf /home/`whoami`/.kde/socket-$OLD_HOST
exit 0
## END ##