Manually deleting computers from the database

[mkuron]

I'm currently writing a script to add and remove computers in the MunkiServer database to integrate that process with a custom deployment workflow.

Adding is simple enough (I just INSERT INTO computers and populate all necessary fields). Deleting looks just as simple (DELETE FROM computers to remove all records with matching MAC address or hostname), however there is a bunch of tables that references the computer by ID either directly or indirectly. I have not been able to extract a comprehensive list from the code (i.e. what happens when you click the Destroy button). Can anybody point me at the right files to look at or post a full list? Here's what I've found so far based on the DB schema and some guessing:

DELETE FROM client_logs WHERE computer_id="[id from computers]" DELETE FROM managed_install_reports WHERE computer_id="[id from computers]" DELETE FROM system_profiles WHERE computer_id="[id from computers]" DELETE FROM warranties WHERE computer_id="[id from computers]" DELETE FROM install_items WHERE manifest_id="[id from computers]" AND manifest_type="Computer" DELETE FROM sp_printers WHERE system_profile_id="[id from system_profiles]" DELETE FROM configurations WHERE id="[configuration_id from computers]" (not sure what this one is for)

[rickychilcott]

That looks like a comprehensive enough list. That said, why not just use Rails to do your cleaning?

You could make a rake task that would be as simple as:

Computer.find_by_mac_address("AA:AA:AA:AA:AA").destroy

Your list DOES look right though.

Side note, now that I look in /app/models/manifest/computer.rb, we should have ":dependent => :destroy" on the has_many relationships too!

[rickychilcott]

I will repeat that manually manipulating the database is a scary proposition long term because requirements may be added (such as validations, new attributes, etc.) and missing those could break your install.

Just to ask again. Why are you doing it this way?

[mkuron]

Simply because I didn't think about the Rake task. Thank you! That certainly is the much cleaner and safer way.

[rickychilcott]

Also, to add a computer, you can use something like:

Computer.create(name: "Test Computer", hostname: "test-computer.domain.com", mac_address: "AA:AA:AA:AA:AA", unit: Unit.first)

Ricky

On Sep 28, 2012, at 2:00 AM, Michael Kuron wrote:

Simply because I didn't think about the Rake task. Thank you! That certainly is the much cleaner and safer way.

— Reply to this email directly or view it on GitHub.

[mkuron]

Here's my ./lib/tasks/computers.rake

namespace :computers do
  task :add, [:name, :hostname, :mac_address, :unit, :environment, :group] => [:environment] do |t, args|
    u = Unit.find_by_name(args[:unit])
    e = Environment.find_by_name(args[:environment])
    g = ComputerGroup.where(:environment_id => e, :unit_id => u, :name => args[:group]).first
    Computer.create(name: args[:name], hostname: args[:hostname], mac_address: args[:mac_address], unit: u, environment: e, computer_group: g) 
    puts "Added #{args}"
  end
  task :delete, [:hostname, :mac_address] => [:environment] do |t, args|
    unless Computer.find_by_hostname(args[:hostname]).nil?
      Computer.find_by_hostname(args[:hostname]).destroy
    end
    unless Computer.find_by_mac_address(args[:mac]).nil?
      Computer.find_by_mac_address(args[:mac]).destroy
    end
    puts "Destroyed #{args}"
  end
end

I can now add and delete computers using commands like

rake1.9 computers:add["tester","tester.local","00:01:02:03:04:05","Default","Staging","Admincomputer"]
rake1.9 computers:delete["tester.local","00:01:02:03:04:05"]

Thank you for your help!

[rickychilcott]

Great! If you want, feel free to make a pull request, someone else might find these to be useful.

Ricky

[mkuron]

Pull request #157

[joraff]

@mkuron Just out of curiosity, are you executing these rake tasks remotely? I'm about to embark on something exactly like this - integration with a custom deployment workflow - and have not determined how best to handle that part.

Sounds like a great reason for munkiserver to have a REST API :)

[mkuron]

I have an Apache running on the same server and as the same user as the MunkiServer instance. It executes a PHP script that calls shell_exec() to call the rake task. I'm using curl to call the PHP script from within a DeployStudio script.

A REST API sounds a bit overkill for this task, but I'm sure Ricky would happily accept your patch...

[rickychilcott]

I think there should be a REST API but were all too busy to make it happen right now. I've had visions of deep integration with DeployStudio using such an API to auto-create a computer in the correct unit and put it into a default group, but hadn't made the time yet.

Michael, do you have a writeup, or could you do one, on your setup and how you're using it? I think it would be really interesting to see how people are making it work, even if it is a bit kludgy. Sometimes seeing it done in a hacky way inspires people enough to make it possible to do it the "right way".

Thanks!

Ricky

On Oct 22, 2012, at 10:28 AM, Michael Kuron wrote:

I have an Apache running on the same server and as the same user as the MunkiServer instance. It executes a PHP script that calls shell_exec() on the rake task. I'm using curl to call the PHP script from within a DeployStudio script.

— Reply to this email directly or view it on GitHub.

[mkuron]

I hope I'll have everything done in a week or two and will then release the scripts to github.

[jnraine]

FWIW, a couple of the desktop support folks in my department have been asking me for a REST API to integrate in their "unified commissioning" app. Basically, an app that creates DNS, AD, and any other records needed.

Sounds like we're all of thinking the same thing on this one!

On Monday, 22 October, 2012 at 7:36 AM, Michael Kuron wrote:

I hope I'll have everything done in a week or two and will then release the scripts to github.

— Reply to this email directly or view it on GitHub (https://github.com/jnraine/munkiserver/issues/156#issuecomment-9665984).

[joraff]

Off-topic --

"deep integration with DeployStudio" - we've all had this dream :) It'd also be nice if they had an open plugin architecture.

I'd like to hear of your plans - the best I've been able to do in the past was just use a deploystudio workflow to kickstart my own ObjC app that did our custom deployment. Fortunately, I was able to keep deploystudio in sync through its API.

[joraff]

@jnraine That's pretty much what our custom deployment process does, minus munki (until now). Looking forward to helping this feature get implemented. See issue jnraine/munkiserver#158

[FromStoneage]

I'm interested in help creating a REST API, though have no experience how other IT management tool might be intergraded.

I guess we can start laying out some requirements how you'd like the API to be designed and consumed.

Let me know what you guys think ? Jordan ?

Cheers, Jonathan Hu

On Mon, Oct 22, 2012 at 9:13 AM, Joseph notifications@github.com wrote:

@jnraine https://github.com/jnraine That's pretty much what our custom deployment process does, minus munki (until now). Looking forward to helping this feature get implemented. See issue jnraine/munkiserver#158https://github.com/jnraine/munkiserver/issues/158

— Reply to this email directly or view it on GitHubhttps://github.com/jnraine/munkiserver/issues/156#issuecomment-9669931.

[joraff]

Best thing would probably be to move this discussion to jnraine/munkiserver#158

[mkuron]

Here's my DeployStudio integration script: https://github.com/mkuron/deploystudio_remote_scripts

[joraff]

Awesome. This will certainly help fulfill the needs of many until a true API exists. Thanks for posting.