| So you've cloned somebody's repo from github, but now you want to fork it and contribute back. Never fear! | |
| Technically, when you fork "origin" should be your fork and "upstream" should be the project you forked; however, if you're willing to break this convention then it's easy. | |
| * Off the top of my head * | |
| 1. Fork their repo on Github | |
| 2. In your local, add a new remote to your fork; then fetch it, and push your changes up to it | |
| git remote add my-fork [email protected] |
Add the following chunk to your existing ISC dhcpd.conf file.
if exists user-class and ( option user-class = "iPXE" ) {
filename "http://boot.smidsrod.lan/boot.ipxe";
}
else {
filename "undionly.kpxe";
}
(or see https://gist.github.com/4008017 for a more elaborate setup
| ddns-update-style none; | |
| deny bootp; #default | |
| authoritative; | |
| include "/etc/dhcp/ipxe-option-space.conf"; | |
| # GREEN (private network) | |
| subnet 10.1.1.0 netmask 255.255.255.0 { | |
| range 10.1.1.100 10.1.1.199; | |
| option subnet-mask 255.255.255.0; |
People
 :bowtie: |
😄 :smile: |
😆 :laughing: |
|---|---|---|
😊 :blush: |
😃 :smiley: |
:relaxed: |
😏 :smirk: |
😍 :heart_eyes: |
😘 :kissing_heart: |
😚 :kissing_closed_eyes: |
😳 :flushed: |
😌 :relieved: |
😆 :satisfied: |
😁 :grin: |
😉 :wink: |
😜 :stuck_out_tongue_winking_eye: |
😝 :stuck_out_tongue_closed_eyes: |
😀 :grinning: |
😗 :kissing: |
😙 :kissing_smiling_eyes: |
😛 :stuck_out_tongue: |
A lot of these are outright stolen from Edward O'Campo-Gooding's list of questions. I really like his list.
I'm having some trouble paring this down to a manageable list of questions -- I realistically want to know all of these things before starting to work at a company, but it's a lot to ask all at once. My current game plan is to pick 6 before an interview and ask those.
I'd love comments and suggestions about any of these.
I've found questions like "do you have smart people? Can I learn a lot at your company?" to be basically totally useless -- everybody will say "yeah, definitely!" and it's hard to learn anything from them. So I'm trying to make all of these questions pretty concrete -- if a team doesn't have an issue tracker, they don't have an issue tracker.
I'm also mostly not asking about principles, but the way things are -- not "do you think code review is important?", but "Does all code get reviewed?".
| 1) Download cntlm rpm package from http://sourceforge.net/projects/cntlm/files/cntlm/ | |
| 2) Login as root | |
| 3) Run command: | |
| $ rpm -ivh cntlm-*.rpm | |
| 4a) Obtain password hash for the configuration file in step 4b (do not put plaintext password in configuration) | |
| $ cntlm -H -d <domain> -u <username> |
| // iMacro CheatSheet - Command Reference | |
| // http://wiki.imacros.net/Command_Reference | |
| // iMacros supports 3 types of variables: | |
| // * The macro variables !VAR0 thru !VAR9. They can be used with the SET and ADD command inside a macro. | |
| // * Built-in variables. They contain certain values set by iMacros. | |
| // * User-defined variables. They are defined in-macro using the SET command. | |
Simple collection of Groovy scripts to help me maintain some Jenkins systems.
See also https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+Script+Console
Please comment & let me know if you have a fork / fixes you'd like to include.
| #!groovy | |
| # Best of Jenkinsfile | |
| # `Jenkinsfile` is a groovy script DSL for defining CI/CD workflows for Jenkins | |
| node { | |
| } |