Apt-get for windows?

[Discord]

Any of you guys seen or tried this?

http://sourceforge.net/projects/windows-get/

Its a pretty good idea, can't believe it hasn't been done before.

[klepto]

Looks like a fuckin headache...

[skroo]

I'm failing to see the point. Most Windows software packages usually come wrappered in some form of installer (MSI, InstallShield, etc.) or as standalone binaries. This really smacks of some 'OMG I <3 TEH LOONIX' weenie's attempt at reinventing the wheel. And having looked more closely at it... Pascal for the commandline client (indifferent there), PHP for the repository. FOR FUCK'S SAKE, PEOPLE, GET IT THROUGH YOUR GODDAMN TINY PEA-BRAINS THAT WEB BASED ADMINISTRATION INTERFACES SUCK ASS!

Kinda cool that I haven't even touched this package yet and it's already got me railing against two of my pet peeves: *nix tools that don't have any reason to exist under Windows being ported to it, and web-based administration interfaces. If they could make it completely dependent on having the default primary-colours XP theme installed, I'd cream my pants with rage.

[TheCotMan]

I'm failing to see the point. Most Windows software packages usually come wrappered in some form of installer (MSI, InstallShield, etc.) or as standalone binaries. This really smacks of some 'OMG I <3 TEH LOONIX' weenie's attempt at reinventing the wheel.

Though this (windows-get) may be a good idea in concept, if it is not supported by Microsoft, it is ultimately unreliable, and an unnecessary additional link in the chain of OS security which (in this case) can weaken the target OS. (Complexity->bugs->holes, Complexity->Error->DoS. trust -> trojan, and more.) MS has a history of changing API, "protocols", or extending existing, protocols to the detriment of existing users/apps of said protocols. This means greater risk for those that might rely on this (windows-get) as a tool to support their systems. (Duct tape should not be considered a long-term support solution.)

FOR FUCK'S SAKE, PEOPLE, GET IT THROUGH YOUR GODDAMN TINY PEA-BRAINS THAT WEB BASED ADMINISTRATION INTERFACES SUCK ASS!

Someone has angered the skroo. Do not poke the skroo with a stick-- you wouldn't like him when he's angry.

Some things work well with web-based administration, but dedicated OS management is not one of them. Web-based administration does not scale well. It is too inviting for managers with little technical knowledge to try to "log in and fix the server" and really screw things up. For *NIX-based systems, it can be a nightmare for people who edit config files with text editors as they fight for control of options that may get erased, reinitialized, lost or commented-out when someone starts up a GUI-Config tool or uses a web-based config tool.

I like the shell. I use the shell. The shell is my friend. The shell and the powers of the shell leveraged with scripting make administration of many boxes less time consuming than GUI or Web-based administration.

However, I find web interfaces for certain, limited, unique and *specific* applications or services very nice when coupled with shell access. Pretend I have only one TrafficShaping device that primarily uses shell access to configure and control it, but was also built to support https based config and control. If I have only one, that could be quite nice. Log in, check the load/throughput history, look at the rules, add new rules, whatever. Simple tasks are often easier with a GUI or Web-based config tool. Another example? Forums like this one, where only one instance is to be supported. Trivial tasks are easily done with a web interface, while a shell could be used to do more complex work.

Kinda cool that I haven't even touched this package yet and it's already got me railing against two of my pet peeves: *nix tools that don't have any reason to exist under Windows being ported to it, and web-based administration interfaces. If they could make it completely dependent on having the default primary-colours XP theme installed, I'd cream my pants with rage.

I've seen tools like windows-get that were made by "experts" and "professionals" that were designed to see what software you have installed, and then look for updates from each vendor for each item and then provide an "easy to use interface to upgrade them."

Yeah. Never found one that worked very well. Even the MS Windows Update tool, with their "driver updates" and other "suggested installs" has been know to cause problems. I've seen MS Windows update tell a user they needed a new nVidia driver. When they installed it, the upgraded OS was now equipped with a nifty new desktop that was a blue screen with white text and a message about dumping pages of memory to disk. Turned out that the driver was for non-Dell boxes, and that Dell users were supposed to manually get an update from Dell instead.

With Windows NT Server 4.0, we were happy to get and install things like the Cygnus tools to make it easier to manage some of our servers. For example, we could dump the registry to a flatfile with windows tools (IIRC) and then either hand edit with a text editor, or use regex with sed or other tools to to mass-modify stuff and then import only specific trees back to the OS. Those tools made us more powerful as admins, because of our *nix experience.

Though I don't think all *nix tools are bad for windows, there are not very many that I would choose to install.

[klepto]

Web-based administration is ok if done right, examples are config files.

ports(freebsd), apt-get(most of the time), and slackpkg(slackware) are 3 good examples.

Although slackpkg is a little bit more chunky, it works.

[Voltage Spike]

It is too inviting for managers with little technical knowledge to try to "log in and fix the server" and really screw things up.

Interesting theory: the understanding of the user drops faster than the ease-of-use of the interface.

For *NIX-based systems, it can be a nightmare for people who edit config files with text editors as they fight for control of options that may get erased, reinitialized, lost or commented-out when someone starts up a GUI-Config tool or uses a web-based config tool.

I think you are railing against specific implementations of a concept (Linux was particularly bad about this). The general process went: I don't like editing this file, I'll create an interface to help me, I have to write a parser for that config file?, I'll just come up with my own config file and convert it. The end result was config files with silly comments like "Don't edit me! Changes will be lost!"

I used to be all for plain text files and simple text editors, but I came to realize that it is easy to make fat-finger mistakes and configuration tools are very helpful in preventing these. For my money, well done web interfaces trump well done custom software interfaces. In the end, it all boils down to a plain text file but at least the interface exists.

Of course, writing more software to configure software increases complexity and introduces more chances for bugs. (Hey! Didn't we cover this topic somewhere? ) I wonder if there has been any effort put forth into a unified configuration interface with some sort of configuration-file schema that validates correctness...

[TheCotMan]

I think you are railing against specific implementations of a concept

Not just that, but the issues of scalability of web based interfaces. Logging into several hundred web pages to select a button seems a waste of time. Granted, I can script such things for simple web pages with a little expect, links/lynx, and some shell scripting, but not all web-based config tools work with tools like links/lynx, and simple changes or updates to the web interface can break expect scripts, "real good."

"Automatic update" is another can of worms. :-(

Also, it is easier to use ssh, with a local key agent with the above, and expect scripts if needed.

I know there are tools for administering many boxes at once, and for automating updates. I've used some, but no matter how many I use, it always seems there is some minor detail that needs to be changed on a bunch of servers that is not covered with the tools available.

I wonder if there has been any effort put forth into a unified configuration interface with some sort of configuration-file schema that validates correctness...

What is, the MS Windows Registry with MS Windows Registry API?
Did I win anything? Oh. I thought this was hacker Jeopardy. ]:>

Maintaining multiple methods for configuring devices increases costs for support, and risk for failure.

I think the world would be much easier for me, if everyone would just do it my way. ]:>

[converge]

"Automatic update" is another can of worms. :-(

shirley, you pun.

[Voltage Spike]

Logging into several hundred web pages to select a button seems a waste of time. Granted, I can script such things for simple web pages with a little expect, links/lynx, and some shell scripting, but not all web-based config tools work with tools like links/lynx, and simple changes or updates to the web interface can break expect scripts, "real good."

It still sounds like implementation details to me.

(Oversimplifying...)

You could: "wget https://server.name/config?buttonA"

Or you could: "ssh server.name some_regular_expression_that_doesn't_understand_co nfig_syntax_and_may_break_things"

I'm not saying that companies are creating their configuration tools properly. I am merely suggesting that they could.

What is, the MS Windows Registry with MS Windows Registry API?

Okay, I saw the horns, but I think you may have missed my meaning. The registry does not prevent me from using invalid syntax, configuring conflicting options, or adding the incorrect key. It simply takes the same mess of config files we have now and provides a common access interface. This isn't a bad idea (I love the Mac OS X equivalent), but it is merely a first step forward.

[TheCotMan]

It still sounds like implementation details to me.

(Oversimplifying...)

You could: "wget https://server.name/config?buttonA"

Or you could: "ssh server.name some_regular_expression_that_doesn't_understand_co nfig_syntax_and_may_break_things"

Not quite the same thing. First, authentication is missing, and though command-line passing of username and password is possible with some command line web clients (as is url encoding with : and @.) I don't like the idea of passwords left in plaintext, or as part of the command line args to show up in a process listing when someone runs a "ps", or in the swapfile, if my shell and bash history and my shell gets swapped out, or in a bash history file that gets flushed to disk, and may be available with forensic analysis even after being overwritten several times.

Also, you make the assumption that the web interface uses simple HTML, not some nifty javascript thing, or cookies for auth, or <feature not supported in wget, sitecopy, links, lynx, but only available in a GUI web browser>.

With ssh, ssh key agent, properly distributed keys, a flatfile of hosts, I can copy the same file to as many hosts as are in a flatfile with a shell "one-liner"

Say you want to update the "hosts" file on a bunch of boxes?
run the key agent, authenticate you keys, and dump the envvar into your shell.
for i in `cat list-of-hosts' ; do scp /tmp/new-hosts root@${i} ; done
500 hosts? No problem. Done.

Need to restart a service?
Since you still have the auth done for your key from the last one:
for i in `cat list-of-hosts' ; do ssh root@${i} /etc/init.d/service restart ; done

Need to update hosts information on a web page with a wget? It can be done with some really nice character substitutions ofr "%20" for each space, and other escaping but then you are limited to the HTTP limits on the size of data that can be sent with a GET. If you want to do a POST, you could probably build a local form with the posted information you wanted to submit as a hidden field, with some clever crafting to enable the submittion of that hidden data, and a modification of the referer name submitted, in case the webapp uses pseudo-security like trusting referrer.

I'm not saying that companies are creating their configuration tools properly. I am merely suggesting that they could.

From where I sit, and with my expereince, GUI+shell supported services/OS do not work as well as shell-only configs with text file edits, or web-only configs with browsers.

Okay, I saw the horns, but I think you may have missed my meaning. The registry does not prevent me from using invalid syntax, configuring conflicting options, or adding the incorrect key. It simply takes the same mess of config files we have now and provides a common access interface. This isn't a bad idea (I love the Mac OS X equivalent), but it is merely a first step forward.

The windows registry is an example of a single location/source for storage of edits. There is capacity with the registry (and its design) to allow for proper synhronization of data inserted into it from many sources, and allow for each change to only single elements.

It allows for modular improvements. A wrapper can be created to intercept requests (in the future) to make sure the admin is not trying to hurt themself with extra checks on data being passed to the registry. Changes can be transparrent to the user and could be applied to any data to be committed to the registry.

Also, consider the case for a key location. That key location is unique. It is set, or it is not, it has a value or it does not; by definition, there is not more than one unique key. If a web app sets it, and someone using regedit sets it, it is only set once to one value. A problem with a config file having multiple assignments for the same variable is not a problem.
(This can and has been a problem with GUI+shell modified config files, where proorly designed web apps may not comment out existing variables from a config file, and multiple entries for the same variable exist. When the admin edits the file, they see their changes are still there, but for some reason the service is not following the configurations specificed. Why? Duplicated variable assignments with the same label, just at different parts of the config file.

This is only one problem "solved" with a registry. There are others.

I will admit it does not solve all of the problems, but consider this:
If the tools to configure services were "smart" enough to tell when something would cause problems if committed, many sysadmins would become unemployed. ]:>

[klepto]

I conclude gentlemen...

Looks like a fuckin headache...

[xwred1]

I heard the whole point of Windows is that installing programs there is way easier.

In Linux, you have to use some confusing apt-get command or synaptic gui.

In Windows, you only have to root around the internets and pick out the most reputable looking tool for what you want from among the overwhelming plethora of choices, log in as administrator, run their installer, check your spyware remover and virus scanner and then fix up any start menu items you didn't like.

[Voltage Spike]

First, authentication is missing

*sigh* I knew you were going to mention this. I know of a couple web browsers that operate similar to the ssh-agent utility, but they are both GUI-based and I'm not sure how well they could be scripted.

To paraphrase: if you need it, it will come.

Also, you make the assumption that the web interface uses simple HTML

I'm not making an assumption about a web interface that doesn't exist. I'm merely suggesting what might be possible if we add a layer of indirection (e.g., a web interface) between the admin and the configuration file.

Say you want to update the "hosts" file on a bunch of boxes?
run the key agent, authenticate you keys, and dump the envvar into your shell.
for i in `cat list-of-hosts' ; do scp /tmp/new-hosts root@${i} ; done
500 hosts?

If all of the hosts require identical configurations, then by all means copy configuration files no matter what interface you use. I might even suggest that maintaining distributed copies of a single file adds unnecessary complexity to the system.

From where I sit, and with my experience, GUI+shell supported services/OS do not work as well as shell-only configs with text file edits, or web-only configs with browsers.

While I'm certainly with you on there, should a poor implementation of the tools today prevent future, hopefully better, evolution of new tools?

There is capacity with the registry (and its design) to allow for proper synchronization of data inserted into it from many sources, and allow for each change to only single elements.

I didn't know that. Why doesn't anybody take advantage of this capability? It would seem like a nice feature if some fool running regedit would be warned against harming himself.

Also, consider the case for a key location. That key location is unique.

Something which I have not seen in any other config files (mainly because everyone else allows for plain-text editing as a last resort). As you point out, though, this design doesn't prevent the creation of "intelligent" configuration interfaces ... in fact, most people in Windows use such interfaces. (They are all different and custom made, but they are in use.)

If the tools to configure services were "smart" enough to tell when something would cause problems if committed, many sysadmins would become unemployed. ]:>

Ah, the truth comes out.

In reality, though, just because the configuration is allowed doesn't mean that it is correct. Sysadmins can breathe easy knowing that there is no substitute for good, old-fashioned intelligence.