Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix up PC installation procedure #1127

Open
goatchurchprime opened this issue May 7, 2019 · 3 comments

Comments

Projects
None yet
3 participants
@goatchurchprime
Copy link
Contributor

commented May 7, 2019

At the bottom of this page is a link to gitlab for installation files. This link is broken.
https://github.com/DoESLiverpool/somebody-should/wiki/PC-Systems

Need to find this files and work out the minimum of software and software keys that we need on these PCs to keep them running and doing the jobs they need to do.

As it's our policy to install free software as and when it's needed, we don't really need lists of what's on each machine -- unless it's been specially configured to do a job related to the equipment that it operates. Only the core proprietary software needs to be properly documented.

@johnmckerrell

This comment has been minimized.

Copy link
Member

commented May 7, 2019

The files are there you just don't have access. We've mostly moved away from GitLab but struggled to move these big files I can give you them locally sometime.

@goatchurchprime

This comment has been minimized.

Copy link
Contributor Author

commented May 7, 2019

Need to know what they are and what they are for. Need to be able to recreate the systems in case one of these PCs goes down. Best to get all the things necessary before such a thing happens.

@MatthewCroughan

This comment has been minimized.

Copy link
Contributor

commented May 7, 2019

The main problem with doing these sorts of things on baremetal is that the backup size can become huge. The more things we have in the space that run on Linux the better, since we can keep a base image of linux, and ZFS snapshots which can then be applied to those base images.

This is one method I'm fond of, since I've got a bit of experience in ZFS now having ran the lan, it's immensely powerful for this sort of snapshotting relatively frequently, without racking up large amounts of data, providing not much has changed on the disk.

Another method is to run these devices on balena, basing their installs on it, meaning we can reproduce and replicate a device at will, like ansible, but easier to maintain, track, as simple as flashing an image to an SD card.

Having homogenous x86 hardware at DoES for all of the appliance systems would also make a lot of sense, considering the odroid h2 is only $110 for a better cpu, gpu, etc than all of the systems we currently have running right now. And it would be capable of running fusion 360 and more, locally. It could be provisioned to run as a thin-client when someone needed to do something more powerful like render.

The most important benefit of using homogeneous hardware is the repeatability of reprovisioning, as people wouldn't need to tear out an old hard drive, they'd just need to follow instructions for a live boot, or reflash an ssd with etcher, or an sd card in the case that we can replace some machines with Pi's.

At some point in the near future, I'm willing to commit to this, document it and set it up in the space. It's honestly not hard, it will be far easier than creating instructions on how to recreate the setup, you would just have to flash the backup to a hard drive, sd card, etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.