Adamos

Если вы можете:
- получив ТЗ, составить план работ по нему и выполнить работы самостоятельно и ответственно, придерживаясь этого плана;
- столкнувшись с необходимостью изучить новый язык или фреймворк, можете взять учебник и заниматься с ним достаточно долго для достижения результата, а когда учебника будет недостаточно - найти и использовать другие источники;
- столкнувшись с незнакомой проблемой, четко ее сформулировать и прикинуть возможности ее решения на основе той информации, которой вы владеете...
- и т.п.
Так вот, если вам это не слабо, то вуз вам может не особенно и требоваться.
Однако большинство вчерашних школьников практически по любому такому пункту теряются и не знают, как действовать либо впадают в прокрастинацию и советы на Тостере. Более того - и вуз не гарантирует, что вы чему-то научитесь. Но среда для этого там подходящая... и кое-какие знания дают, но это уже вторично, особенно для IT, где все устаревает раньше, чем попадает в учебники.

На несколько доменов или на несколько серверов?
Для одного домена у пользователя логично предвидеть как минимум две установки: на боевой сервер и на тестовый. IP тут несколько неуместен...

появилось желание по фрилансить, с одним будет тяжко

Из какой маркетинговой задницы выковыривают такие суждения?
Я понимаю, мне тесновато на 19" 4:3, но у тебя-то в одном 29" таких воткнуто две штуки с припевом.
Что ты по ним раскладывать собрался, фрилансер?
Страницы интернета, которые должны в смартфонный экран влезать?
Код, в котором после сотни символов в строке читаемость упадет до нуля?
Терминал, изначально рассчитанный под 80х25 символов?..

Чайники так мучаются с этим вопросом, как будто для него нет простого ответа.
Если вам нужно типовое решение (то, что уже сотни раз реализовано в интернете) - вам нужна CMS.
Если вы хотите сделать что-то, чего никто не делал или каждый делает по-своему - фреймворк.
Магазин - это, как правило, заведомо первая категория.

Если у вас на сервере исполняется что угодно от клиентов - стоит быть готовым, что это "что угодно" использует эксплойт с повышением прав до рута и похерит весь сервак.
Нет, правами на папки это не решается.
Эксплойты, пробивающие виртуализацию, тоже случаются, но реже, конечно.

Стоит локализовать проблему: что именно загружают клиенты на сайт и как это используется. Исходя из этого уже плясать дальше.
Например, если это исключительно мультимедия/документы/архивы - просто исключите возможность, что они будут каким-то образом обрабатываться на сервере.
Если же это полноценные сайты и клиенты загружают произвольные скрипты - ну, режьте возможности обработчика... и разделите права на папки, конечно.

Картинки могут использовать три вида уязвимостей:
1. В настройках вашего сервера. Если у вас можно загрузить картинку и обратиться к ней, и она останется неизменной и может оказаться не картинкой, а скриптом, который выполнится на сервере. Искореняется проверкой MIME и отдачей статики без обработки.
2. В библиотеках пользователя (старые версии libpng, например). В дикой природе практически не встречается, но если угодно, можно перекодировать файлы, используя ImageMagick.
3. И вот тут всплывает третий вариант: атака самого IM всякими форматами, в которых поддерживаются внешние ссылки. Искореняется ограничением того, что вообще можно загрузить и обработать, PNG и JPG, и последующей обработкой их IM.
На практике получаем, что проверка MIME и перекодирование IM решает все ваши проблемы. Заодно и еще одну - вам не навалят файлы такого размера, что внезапно кончится место на хостинге.
А вынос на другой сервер - вообще ни о чем. Только лаги увеличивать. Так делают для очень высоконагруженных проектов... но там и таких вопросов не задают ;)

Если в самих файлах тоже "только текст, никаких наворотов" - проще сразу конвертировать этот текст в HTML и потом пристегивать к админке совершенно любой из сто лет доступных продвинутых редакторов.

Предлагаю начать с этого источника ;)

Без знания хотя бы одного чисто серверного языка (пых/питон/жаба/дотнет) называться фулстеком - значит заранее обманывать ожидания работодателя. И завалиться на собеседовании, если действительно удосужатся проверить, насколько "фул ваш стек".
Баловство с Нодой - скорее бонус к специализации фронтэндера, чем претензия на фулстек.

Один день чтения документации по SVG, например.
Нет, SVG - это вовсе не обязательно "картинки".
Есть простой путь - нарисовать пару узлов в Inkscape, сохранить и посмотреть в текстовом редакторе, что получилось, поглядывая в документацию по SVG.

Труп Интернет Эксплорера на пути веб-технологий наконец истлел.
Следующей тушкой дорогу перегораживает Ёксель.

На кой вам таблица Ёкселя? Только из тех соображений, что юзер привык по ней бегать, в любых изменений боится? Так вы в веб тянетесь. В вебе нужна не каша в клеточку (Ёксель), а данные. К счастью, данные из вашей таблицы без особого труда выдираются и обрабатываются. Бегать по контролам на веб-страничке, внезапно, ничуть не сложнее. Визуализировать, добавлять графики и диалоги - тоже нетрудно. Так, может, забыть уже про этого кадавра и просто сделать пользователю удобный интерфейс, не завязанный на ОС?

На рынке достаточно изобретателей универсальных CRM, переплюнуть их - никаких шансов, при этом надо понимать, что никто из них так и не смог создать ничего такого волшебного, как задумывалось - чтобы можно было слегка поднастроить и получить годный инструмент для конкретного заказчика. Все равно программисту нужно дописывать конкретную реализацию конкретных хотелок.
Есть другая сторона этого рынка - нишевые инструменты для тех, кому универсальные либо слишком громоздки, либо написать с нуля проще, чем базироваться на универсальном.

Главная засада в том, что писать CRM, отталкиваясь от своих теоретических представлений о том, что там должно быть - заведомая работа на корзину. На этапе внедрения все эти красивые теории летят коту под хвост, и если система недостаточно гибка, чтобы завязываться узлом в нужном направлении - она просто не работает.