Puppy Linux Discussion Forum

[gcmartin]

Many will find this complex. Many will find this complicated. Some will find it challedging, but together, I think this community can address this to a very High degree of resolution that will survive future Puppy and kernel upgrades. Externally, there appears to be a problem with Puppy design.

I expect that Objections will be heard within the community

This post is structured as follows;

1. History of HOSTNAME
   
2. History of the "hostname - ROX - "Puppy-Linux filesystem" problem
   
3. Current status
   
4. The Problem
   
5. Request for community assistance

History of HOSTNAME
Without boring anyone, I wll summarize. Since the middle '70, ALL communications and later LAN administrators have been taught that they will never be two devices on the LAN with

• same MAC
  
• same hostname
• same IP address

These identify the "machine-readable ID" as well as the "machine-readable name" of every device on the LAN. Every LAN technician who was ever taught by anyone, anywhere, knows to NOT make the mistake of duplicating this information on ANY two PC on a local LAN.in the same subnet.

These items, it is taught, is a standard that we are suppose to abhere to. And there are many very, very good reasons this is done. The standard says, "Every device will have a unique one of each of these."

Puppy/WARY have long been approaching the LAN as if it is the ONLY PC on the LAN, and that the Puppy PC will use its NIC to traverse the LAN to enter and use the internet.

Over the years, many of us have sort and used PUPs on our LAN where there are other PCs. Most recently, now, many of us are beginning to populate our LANs with multiple PUPs.

Even though the MAC are unique, the hostname(s) are NOT UNIQUE. And, in many cases they are the same for multiple Puppy devices on you LAN. This defies architectural standards defined and causes issues on the local PC and local LAN. Many non-PUP distros handle effectively.handled this problem with the hostname management withn their distros; namely Ubuntu, Fedora, Suse, etc.

In Puppy, this appears, that it was never revisited until fall,2010 when Shinobar step forward and began offering a solution that has been adopted by several distro developers here for other reasons, than the one we are discussing here.

History of the " 'hostname' - 'ROX' - 'Puppy-Linux filesystem' " problem
Almost simultaneous with Shinobar's solution, a discovery was made that there was a "LINK" to the /etc/hosts file contents and the behavior of the Puppy filesystem when using ROX. Seems that there is a slowness/delay in ROX behavior on the desktop when this file is NOT set properly. Again, Shinobar, enters the arena and upgrades his tool to overcome this delay problem by insuring that the hostname and the /etc/hosts contains the proper information which removes the delay/slowness we all had had for years with Puppy and ROX.

Now, as nice of a solution that Shinobar presents with the tool he developed for this community, if a savvy Linux user(s) did NOT use his tool, and tried to manually makes some needed changes to the system by modifying some key files or system variables, he runs the risk of filesystem things not working properly.

Current status
Today, no Puppy I have found is delivered with tools necessary to change "ALL" related system variables when the hostname is changed in the system. Nor, is there any directions for addressing how to get hte system to conform so that filesystem performance matches what an OTB filesystem provides in its ROX speed and performance.

The Problem:
In any Puppy system, the following PUPPY System data does NOT agree
when ANY changes to the following is necessary

• hostname from the Linux hostname command
  
• Linux Environment Variable HOSTNAME
  
• files
  
  • /etc/hosts
    
  • /etc/hostname

Why is this a problem?
This is system data. And from time to time various application rely on getting authoritative data from the system's files and variables. This information should and must be kept consistent.

1. All of these system items should agree when a user begins to use the Puppy desktop and wants to use his machine for ANY LAN operation
   
2. All of these items should agree when a user has a need to change the system's hostname for ANY reason.

Important NOTE
It seems that when the fields agree, for some unknown reasons, ROX in PUPs seems to have superior performance than when these fields do NOT agree.

Request for community assistance
Would anyone, anyone share any thoughts on

• why this dilemma exist in Puppy design?
  
• what would be the "right" place for a solution to be for distro builders?
  
• What should the solution look like?
  
• What should be an acceptable Puppy methodolgy for changing the system hostname
• when its necessary to do so?

I fully recognize that this topic is a little difficult for some to try to grasp what's going on, here, but many of the develpers in this community fully realize what's happening.

Please help all of us on this if you can.
P.S. PLEASE understand that the hostname may need to be changed when there is need after the system may have been running for awhile. We should expect that the system administrator can/will at any time change the system hostname to match LAN needs.

[8-bit]

I have been with Puppy for a while, and with a local home lan with wireless as well as wired and Puppy on my main PC as well as on a few laptops that connect wirelessly, I can see that having a few PCs with the name "PuppyPC" could prove to be a problem.
Why can't one just implement startup code that asks what the user wants to name his PC?
It would then change all needed data accordingly.
A utility could also be added under networking to change the name later.

Also, my Lan keeps info for every PC that uses it for future connections.
I had to connect a laptop wired to set up a router.
When I later tried to connect the same laptop wirelessly, I had problems as the router assumed the laptop was still hardwired.

[bigpup]

In Lucid Puppy 5.2.5
Personalize Settings
Has option to change hostname
Doesn't this do what you are looking for?

[nooby]

This maybe explain then why some people have problems with wifi set up?
If the router remember another setup with same hostname?

Just me wild guessing. I've only set up wifi with smartphones.

[Terryphi]

gcmartin: I don't quite understand why this is a problem. I have 2 PCs on my LAN and my router knows them by the name of the user (e.g. Jack-PC and Jill-PC). On these PCs I can run any OS (Windows, various Puppy variants, Ubuntu and Linux Mint) with any hostname and they connect without problem. Does your router not allow you to rename attached devices?

Are you saying that Puppy works in a fundamentally different way from other Linux distros where changing the hostname is simply a matter of editing /etc/hosts and then everything just works on reboot?

Using a wireless network can be more complicated for the reason described above by 8-bit. How important is hostname anyway? Surely the router is only interested in the names of the attached devices (which can be changed within the router settings)?

[nooby]

Terry wrote

[01micko]

gcmartin

I see your point and I propose a simple solution.

/etc/hosts and /etc/hostname are hard coded into the puppy iso. Therefore when when the environment variable $HOSTNAME is run it's going to be "puppypc" until a reboot. Environment variables are set up by the script /etc/profile at boot. At very first boot we need to run something that sets a new hostname before that is run.

Now, immediately before /etc/profile is run /etc/rc.d/rc.sysinit is run and that seems to depend on /etc/hostname's existence.

@ line 376 /etc/rc.d/rc.sysinit

[jamesbond]

/etc/hostname is used to set kernel's hostname during system boot-up. The code is in rc.sysinit.
/etc/hosts is used to translate a name to an IP address.
They serve two different purposes and generally they don't have to match. But it's good to ensure that system's hostname is resolvable to an IP address.
In Fatdog64, during creation of the save file the system will ask you (optionally) change the default hostname ("fatdog64") to something else.

[jamesbond]

[rcrsn51]

Correct me if I'm wrong, but the hostname is only important if the computer is running a service that advertises the name over your network. In how many Puppy situations does that occur? I can only think of one and it is easily resolvable.

[jamesbond]

[rcrsn51]

[rcrsn51]

[gcmartin]

This is indeed, a system level change requirement.

@01Micko proposes an acceptable solution for OTB Live media booting and beyond. This would create and preserve uniqueness for each and every use of the Live media boot process.

@JamesBond accurately indicates some cautions that should be understood and abhered to. The ROX problem is tied to the hostname, somewhere somehow and appears to maybe make use of couple of the 4 fields in its operation. When ROX is getting compatible information, processing speeds. When it doesn't, processing slows in its presentation on desktop.

@Rcrsn51 seems focused merely on SAMBA, yet I have repeated said ROX as well.

AND, how many of us know if there are other apps who would experience improved behavior it the Puppy system would be in agreement of these fields.

I believe that the correct approach is to have all the fields consistent for any internal system application's use. All internel applications should, at the very least, be seeing the system name consistently whenever they use any of these system fields, NOT as it is today. These are NOT application owned setting....these are system level settings.

So any solutions addressed will benefit all of us in our use of Puppy, internally for local applications and externally when the hostname is advertised appropriately.

[gcmartin]

@Terryphi, Thanks for asking. You are helping all of us to see the problem thru your questioning like this.