Как импортировать модули в PowerShell

 

http://winintro.ru/windowspowershellhelp.ru/html/3be86334-7efa-4ccd-952e-54afe47977a2.htm

 

РАЗДЕЛ
	about_Modules

КРАТКОЕ ОПИСАНИЕ
	Описание процедур установки, импорта и использования модулей 
	Windows PowerShell

ПОЛНОЕ ОПИСАНИЕ
	Модуль - это пакет команд Windows PowerShell, таких как 
	командлеты, поставщики, функции, переменные и псевдонимы. 

	Составляя команды, пользователи могут организовывать их с помощью 
	модулей и передавать их другим пользователям. Получив такой 
	модуль, пользователь может добавить содержащиеся в нем команды в 
	сеанс Windows PowerShell и использовать их аналогично встроенным 
	командам.

	В этом разделе описывается, как использовать модули Windows 
	PowerShell. Сведения о процедуре создания модулей Windows 
	PowerShell см. в разделе "Создание модуля Windows PowerShell" в 
	библиотеке MSDN по адресу http://go.microsoft.com/fwlink/?LinkId=144916.


 ИСПОЛЬЗОВАНИЕ МОДУЛЯ
	Чтобы воспользоваться модулем, выполните следующие действия.

		1. Установите модуль. (Обычно это выполняется автоматически.) 
		2. Импортируйте модуль в сеанс Windows PowerShell.
		3. Найдите команды, добавленные модулем.
		4. Выполните эти команды.
	 
	В данном разделе описано, как выполнить эти задачи. В нем также 
	содержатся другие полезные сведения об управлении модулями.


 УСТАНОВКА МОДУЛЯ
	Если модуль предоставлен в виде папки с файлами, необходимо 
	установить его на компьютер, чтобы можно было импортировать его в 
	Windows PowerShell.

	Обычно модули устанавливаются автоматически. В Windows PowerShell 
	имеется несколько предустановленных модулей. В Windows Server 
	2008 R2 можно воспользоваться мастером добавления компонентов 
	(в диспетчере сервера), чтобы автоматически установить выбранные 
	компоненты. Многие модули поставляются с программой установки, 
	выполняющей установку модуля.

	Для установки модуля, предоставленного в виде папки, выполните 
	следующие действия.

		1. Создайте каталог "Modules" для текущего пользователя, если 
		он не существует. 

		 Для этого введите следующую команду:

			 new-item -type directory -path 
			 $home\Documents\WindowsPowerShell\Modules							 

		2. Полностью скопируйте папку модуля в каталог "Modules".

		 Скопировать папку можно любыми средствами, включая 
		 проводник, программу Cmd.exe и Windows PowerShell.

		 В Windows PowerShell для этого воспользуйтесь командлетом 
		 Copy-Item. Например, чтобы скопировать папку "MyModule" из 
		 каталога "C:\ps-test\MyModule" в каталог "Modules", 
		 введите следующую команду:

			 copy-item -path c:\ps-test\MyModule -dest 
			 $home\Documents\WindowsPowerShell\Modules

	Установить модуль можно в любое местоположение, однако если 
	всегда устанавливать их в местоположение модулей по умолчанию, 
	ими проще управлять. Дополнительные сведения о местоположении 
	модулей по умолчанию см. в разделе "Местоположения модулей и 
	переменная PSModulePath".



 ПОИСК УСТАНОВЛЕННЫХ МОДУЛЕЙ
	 Если модуль установлен, его можно импортировать в сеанс Windows 
	 PowerShell. 

	 Чтобы найти модули, установленные в местоположении модулей по 
	 умолчанию, в командной строке Windows PowerShell введите следующее:

		 get-module -listAvailable


	 Чтобы найти модули, уже импортированные в сеанс, в командной 
	 строке Windows PowerShell введите следующее:

		 get-module

	 Дополнительные сведения о командлете Get-Module см. в разделе 
	 Get-Module.



 ИМПОРТ МОДУЛЯ
	Чтобы выполнить команды, содержащиеся в модуле, импортируйте его 
	в сеанс Windows PowerShell.

	Чтобы импортировать модули в текущий сеанс из местоположения 
	модулей по умолчанию, используйте следующий формат команды:

		import-module <имя_модуля>

	Например, следующая команда импортирует модуль BitsTransfer в 
	текущий сеанс.

		import-module BitsTransfer

	 
 
	Чтобы импортировать модуль, не находящийся в местоположении по 
	умолчанию, укажите в команде полный путь к папке этого модуля. 

	Например, чтобы добавить в текущий сеанс модуль TestCmdlets, 
	расположенный в папке "C:\ps-test", введите следующую команду:

		import-module c:\ps-test\TestCmdlets

	Чтобы получить дополнительные сведения о добавлении модулей в 
	сеансы, см. Import-Module.



 ИМПОРТ ВСЕХ МОДУЛЕЙ В СЕАНС WINDOWS POWERSHELL. 
	В операционных системах Windows 7 и Windows Server 2008 R2 задача 
	"Импортировать все модули" открывает сеанс Windows PowerShell, 
	содержащий все доступные модули и оснастки Windows PowerShell.

	Чтобы запустить сеанс Windows PowerShell со всеми доступными 
	модулями и оснастками Windows PowerShell, выполните следующие 
	действия.

	-- Щелкните правой кнопкой мыши значок Windows PowerShell на 
	 панели задач и выберите "Импортировать все модули".

	Примечание. В Windows Server 2008 R2 значок Windows PowerShell по 
				умолчанию закреплен на панели задач. Впрочем, чтобы 
				появилась задача "Импортировать все модули", необходимо 
				один раз запустить Windows PowerShell.

	Чтобы импортировать в сеанс все доступные модули в других версиях 
	Windows, в командной строке Windows PowerShell введите следующее:

		get-module -listAvailable | import-module


   
 ПОИСК КОМАНД В МОДУЛЕ
	После того как модуль импортирован в сеанс Windows PowerShell, 
	можно использовать содержащиеся в нем команды.

	Чтобы найти добавленные модулем команды, в командной строке 
	Windows PowerShell введите следующее:

		get-command -module <имя_модуля>

	Например, чтобы найти команды, добавленные модулем BitsTransfer, 
	введите следующее:

		get-command -module BitsTransfer

	Дополнительные сведения о командлете Get-Command см. в разделе 
	Get-Command.



 ПОИСК СПРАВКИ ПО КОМАНДАМ В МОДУЛЕ
	Если модуль содержит разделы справки по командам, которые он 
	экспортирует, их можно вывести с помощью командлета Get-Help. 
	Используйте команду такого же формата, как и для любого раздела 
	справки Windows PowerShell. 

	Чтобы найти раздел справки по содержащимся в модуле командам, в 
	командной строке Windows PowerShell введите следующее:

		get-help <имя_команды> 

	Чтобы вывести более подробную справку, введите следующее:

		get-help <имя_команды> -detailed

	Например, чтобы найти подробную справку о командлете 
	Start-BitsTransfer, введите следующую команду:
	 
		get-help Start-BitsTransfer -detailed

	Дополнительные сведения о модуле Get-Help см. в разделе Get-Help.




 УДАЛЕНИЕ МОДУЛЯ
	Если удалить модуль, добавленные им команды удаляются из сеанса. 

	Чтобы удалить модуль из сеанса, используйте следующий формат команды:

		remove-module <имя_модуля>

	Например, следующая команда удаляет модуль BitsTransfer из 
	текущего сеанса.

		remove-module BitsTransfer

	Операция удаления модуля отменяет операцию его импорта. При этом 
	установка модуля не отменяется. Дополнительные сведения о 
	командлете Remove-Module см. в разделе Remove-Module.



 ИМПОРТ МОДУЛЯ В КАЖДОМ СЕАНСЕ
	Команда Import-Module импортирует модули в текущий сеанс Windows 
	PowerShell. Она затрагивает только текущий сеанс.

	Чтобы модуль импортировался в каждый новый сеанс Windows 
	PowerShell, добавьте команду Import-Module в профиль Windows 
	PowerShell.

	Дополнительные сведения о профилях см. в разделе about_Profiles.   

  
 МЕСТОПОЛОЖЕНИЯ МОДУЛЕЙ И ПЕРЕМЕННАЯ PSMODULEPATH
	Для модулей Windows PowerShell предусмотрено два местоположения 
	по умолчанию: одно для системы, другое для текущего пользователя.

		Для системы:  $pshome\Modules 
						(%windir%\System32\WindowsPowerShell\v1.0\Modules)

		Для текущего  $home\Documents\WindowsPowerShell\Modules 
		пользователя:   (%профиль_пользователя%\Documents\WindowsPowerShell\Modules)

					 - или:

					$home\My Documents\WindowsPowerShell\Modules 
						(%профиль_пользователя%\My Documents\WindowsPowerShell\Modules)



		Примечание. Чтобы добавить или изменить файлы в каталоге 
					%Windir%\System32 в операционных системах Windows 
					Vista, Windows Server 2008 и Windows более поздних 
					версий, запустите Windows PowerShell с параметром 
					"Запуск от имени администратора".


	Чтобы изменить местоположения модулей по умолчанию для системы, 
	измените значение переменной среды PSModulePath ($env:psmodulepath). 
	Переменная среды PSModulePath основана на переменной среды 
	Path и имеет тот же формат. 
 

	Чтобы отобразить местоположения модулей по умолчанию, введите 
	следующую команду:

		$env:psmodulepath

	Чтобы добавить местоположение модулей по умолчанию, используйте 
	следующий формат команды:

		$env:psmodulepath = $env:psmodulepath + ";<путь>"

	Точка с запятой (;) в этой команде отделяет новый путь от 
	предыдущего пути в списке.


	Например, чтобы добавить каталог "C:\ps-test\Modules", введите 
	следующую команду:

		$env:psmodulepath + ";c:\ps-test\Modules"


	После добавления пути в переменную PSModulePath команды 
	Get-Module и Import-Module действуют в том числе на модули в 
	каталоге, на который указывает этот путь.
	 
	Задаваемое значение влияет только на текущий сеанс. Чтобы 
	сохранить изменение, добавьте эту команду в профиль Windows 
	PowerShell или откройте диспетчер "Система" на панели управления 
	и измените значение переменной среды PSModulePath в реестре.

	Дополнительные сведения о переменной PSModulePath см. в разделе 
	about_Environment_Variables.
   


 МОДУЛИ И КОНФЛИКТЫ ИМЕН
	Конфликт имен происходит, когда в сеансе имеется несколько команд 
	с одинаковым именем. При импорте модуля возникает конфликт имен, 
	если содержащиеся в нем команды имеют такие же имена, как команды 
	или элементы, уже имеющиеся в сеансе. 

	Конфликты имен могут возникать в результате скрытия или замены команд.
		-- Скрытие. Скрытой называется команда, не выполняемая при 
		 вводе ее имени, но выполняемая другими способами 
		 (например, с указанием имени модуля или оснастки, из 
		 которой добавлена команда).

		-- Замена. Замененной называется команда, поверх которой 
		 записана команда с таким же именем. Даже если удалить 
		 модуль, являющийся причиной конфликта, выполнить 
		 замененную команду можно только после перезапуска сеанса.


	Команда Import-Module может добавить команды, скрывающие или 
	заменяющие команды в текущем сеансе. Кроме того, команды в 
	текущем сеансе могут скрыть команды, добавленные модулем. 

	Чтобы предотвратить конфликт имен, используйте команду 
	Import-Command с параметром Prefix, чтобы создать уникальные 
	имена для импортируемых команд.

	Команду Import-Module также можно использовать с параметрами 
	Alias, Cmdlet, Function и Variable, чтобы выбрать только те 
	команды, которые требуется импортировать, исключив команды, 
	вызывающие конфликт имен в сеансе.

	Даже если команда скрыта, можно выполнить ее, указав (помимо ее 
	имени) имя модуля или оснастки, из которой она добавлена. 

	Правила приоритета команд Windows PowerShell определяют, какая из 
	конфликтующих команд запускается в сеансе, содержащем команды с 
	одинаковыми именами.

	Например, если сеанс содержит функцию и командлет с одинаковым 
	именем, по умолчанию Windows PowerShell выполняет функцию. Если 
	сеанс содержит команды одинакового типа (например, два 
	командлета) с одинаковым именем, по умолчанию выполняется 
	команда, добавленная последней. 

	Дополнительные сведения, включая пояснения правил приоритетов и 
	инструкции по запуску скрытых команд, см. в разделе 
	about_Command_Precedence.
	 
	 
	 
 МОДУЛИ И ОСНАСТКИ
	Команды из модулей и оснасток можно добавлять в сеанс. Из модулей 
	можно добавлять все типы команд, включая командлеты, поставщики и 
	функции, а также элементы, такие как переменные, псевдонимы и 
	диски Windows PowerShell. Из оснасток можно добавлять только 
	командлеты и поставщики.

	Тогда как функции, псевдонимы, переменные и диски можно добавлять 
	в сеанс путем ввода с клавиатуры или запуска добавляющего их 
	скрипта, все командлеты и поставщики, содержащиеся в сеансе, 
	добавляются только из модулей и оснасток.

	Прежде чем удалить модуль или оснастку из сеанса, с помощью 
	следующих команд определите, какие команды будут при этом удалены. 

	Чтобы определить, откуда командлет добавлен в сеанс, используйте 
	следующий формат команды:

		get-command <имя_командлета> | format-list -property verb, 
		noun, pssnapin, module

	Например, для поиска источника командлета Get-Date введите 
	следующую команду:

		get-command get-date | format-list -property verb, noun, 
		pssnapin, module 
	Дополнительные сведения об оснастках Windows PowerShell см в 
	разделе about_PSSnapins.


CМ. ТАКЖЕ
	about_Command_Precedence
	about_PSSnapins
	Get-Command
	Get-Help
	Get-Module
	Import-Module
	Remove-Module

Getting all Licensed Office 365 users with PowerShell

 

http://support.microsoft.com/kb/2777380

 

To get started, open a SharePoint Online Management Shell, and connect to Office 365 via the cmdlet Connect-MsolService. When prompted, enter the corresponding administrator credentials.

To get a list of all users within your tenant (both those with licenses assigned to them and those without), you can now use the cmdlet Get-MsolUser. Execute Get-MsolUser | Get-Member | Out-GridView to get a nicely formatted list of all available properties for the user objects returned by Get-MsolUser.

Of particular interest is the property isLicensed, which indicates whether a user has a license assigned (TRUE) or not (FALSE). It is now possible to filter the users returned by Get-MsolUser and only see those that are licensed by running the command Get-MsolUser | Where-Object { $_.isLicensed -eq "TRUE" }
Note: By using "FALSE" instead of "TRUE", you can get a list of all users that do currently not have any license assigned to them.

The list of licsensed user can now be processed further, for example by exporting it to a CSV file that can be opened in Excel for reporting purposes or further analysis: Get-MsolUser | Where-Object { $_.isLicensed -eq "TRUE" } | Export-Csv c:\LicensedUsers.csv

Note that this exports all available properties for the licensed users. To export only specific properties, you can use the Select-Object cmdlet to specify which properties to use. As an example, only UserPrincipalName, DisplayName, Country, and Department will be exported:
Get-MsolUser | Where-Object { $_.isLicensed -eq "TRUE" } | Select-Object UserPrincipalName, DisplayName, Country, Department | Export-Csv c:\LicensedUsers.csv

 

http://workingwith365.wordpress.com/2011/10/29/administering-office-365-with-powershell/

 

Administering Office 365 with PowerShell

Leave a Comment Posted by Brendan Erofeev on October 29, 2011

I like to think of PowerShell as the Windows tool that finally convinced Unix guys that Microsoft admins can do more than just drive a GUI.

PowerShell is Microsoft’s task automation framework, consisting of a command-line shell and associated scripting language built on top of, and integrated with the .NET Framework. (http://en.wikipedia.org/wiki/Windows_PowerShell)

So, what can you do with it?  Almost anything!  More and more, PowerShell is becoming the tool of choice for administration on Microsoft platforms, and Office 365 is no exception.  In fact, like most PowerShell administer-enabled applications, there are things you can do in PowerShell that you can’t do in the GUI.

Most of the posts on this site will reference administering Office 365 using PowerShell in some way (whether it be the main focal point of the post, or an alternative to achieving the goal), so this article will serve as a reference on how to connect to difference Office 365 services using PowerShell.

General Administration using the Microsoft Online Services PowerShell Module:

The Microsoft Online Services PowerShell Module can downloaded from here:

Microsoft Online Services PowerShell Module 32 Bit

Microsoft Online Services PowerShell Module 64 Bit

Once you have downloaded and installed the bits, launch the module by finding it in your start menu (should be under All Programs > Microsoft Online Services).

Once you have it fired up, type:

connect-msolservice

You should now be prompted for your Office 365 credentials:

Once you enter your credentials, and press OK, your PowerShell window will take few seconds to connect, and then give you back your prompt:

A little anti-climactic isn’t it?

But…now you are connected.  Try typing:

get-msoluser

Bam!  A list of Office 365 users.

So, where from here?  What else can you do?  Type:

get-command -noun msol*

This will give you a list of cmdlets that you can use for Office 365 administration (at the time of writing, there are 49 cmdlets).  OK OK, so how do I USE these cmdlets?

The beautiful thing about PowerShell, is it was designed to be easy to learn.  Firstly, all PowerShell cmdlets come in the form of Verb-Noun.  What this means is that figuring out what cmdlet will do the job you are trying to do is as easy as thinking of what you would call it yourself.

If I want to add a new user, I use “New-MsolUser”  If I want to remove a user, I use “Remove-MsolUser”.  If I want to do anything to do with a user, I can enter:

Get-Command *MsolUser

And a list of cmdlets will be returned that are used to manage users.

If I want to know how to use “New-MsolUser”, I can enter:

Get-Help New-MsolUser

And if I want a practical example of the use so that I can learn by example, I can enter:

Get-Help New-MsolUser -examples

Exchange Online Administration using a Remote PowerShell Session

To administer Exchange Online, instead of using the Microsoft Online Services module, you connect to a remote PowerShell session.

The first thing to do is start a regular PowerShell session with administrative rights.  Navigate to All Programs > Accessories > Windows PowerShell, right click on “Windows PowerShell” and select “Run as administrator”

Once PowerShell is open, we need to do a bit of tweaking before we can connect to the remote session.  The first tweak is to adjust the execution policy to allow local scripts to run.

NOTE: Adjusting your execution policy lowers the security of PowerShell.  Make sure to read and understand this article before adjusting your execution policy.

OK, now, lets adjust the execution policy to RemoteSigned.  This level will enable you to run local scripts, or scripts from other sources, but will not allow you to run scripts downloaded from the internet.

enter the following command into PowerShell:

Set-ExecutionPolicy RemoteSigned

You will be asked to confirm the change, press enter.

The next step is to build a function to connect to Exchange Online (not necessary, but a definite time saver) and place it into your PowerShell profile.  Enter into PowerShell:

test-path $profile

If you receive back “True”, this means that you already have a PowerShell profile, so we can just add the function to it.  If you receive back “False”, type the following (Only if you received back “False”):

New-Item -Path $profile -Type File -Force

The above line just created you a new profile.  ”New-Item” is the command to create a new item, “$profile” is a pre-defined value in PowerShell, and points to your profile (or where it should be), and the -Force command forces the file, and any directories along the way, to be created.

Now that you have a profile (or if you already had one previously), you can type:

notepad $profile

This will open your profile in notepad, so that we can add our function to it.  Add the following lines to your profile:

Function Connect-ExolService
{
$cred = Get-Credential
$ExchangeOnline = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $cred -Authentication Basic -AllowRedirection
Import-PSSession $ExchangeOnline -Prefix Exol
}

And save it.

So, what does this function do? I’ll break it down:

Function Connect-ExolService

First, we define our function.  I am calling mine “Connect-ExolService”

$cred = Get-Credential

Next, we create a variable “$cred”, and prompt the user for credentials to store in it “Get-Credential”

$ExchangeOnline = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $cred -Authentication Basic -AllowRedirection

Then, we create a new variable called “$ExchangeOnline” and store a “New-PSSession” in it.  our “-ConnectionUri” points at “https://ps.outlook.com/powershell”, but we also have the “-AllowRedirection” switch, so when we connect, our connection will be redirected to the Exchange server that hosts our tenant.

Import-PSSession $ExchangeOnline -Prefix Exol

Finally, we import the session.  Importing a session imports command such as cmdlets, functions, and aliases into the current session.  The important part to note here is the “-Prefix Exol”.  What this tells PowerShell to do is place “Exol” in front of the noun in every command imported.  The importance of this will be made apparent shortly.

Ok, so now we have our shiny new function saved into our profile.  We must reload our profile before we can use the function.  To do this, type the following:

.$profile

Ok, now we are all geared up to manage our Exchange Online via PowerShell!  Lets try our function:

Connect-ExolService

The first thing we get is a prompt for credentials.  Enter your credentials, and press OK.

Next, all of our commands are loaded from the remote session, and now we are ready to work.

Remember the “-Prefix Exol” we created earlier?  Well, this is where it comes in handy.  Enter the following command:

Get-Command -Noun Exol*

What you have now is a list of imported commands from the Exchange Online remote session.  All of these commands are used to manage Exchange Online (230 at the time of writing).  That’s a LOT of commands….well, not really when compared to on-premises Exchange, which has over 600!.  But nontheless, not easy to take in all at once.  So lets see them a-page-at-a-time:

Get-Command -Noun Exol* | Out-Host -Paging

Where to from here?  Well, if you have administered Exchange on-premises using PowerShell, you should be in your element right about now.  Remember though, Exchange Online is a Convenience vs Control trade-off, so you won’t see all of the cmdlets you are used to working with, you only get the ones that are applicable to managing the parts of Exchange Online that you are allowed to manage.

If you have never touched Exchange on-premises, or PowerShell, remember, “Get-Command” and “Get-Help” are your two best friends.  Do not underestimate them, as 99% of the time, they have the answers you are looking for.

Настройки подключения к БД в различных CMS

 

В Joomla есть файл configuration.php, в котором есть строчки:

var $host = 'сервер';
var $user = 'имя_пользователя';
var $db = 'имя_базы_данных';
var $password = 'пароль';

В WordPress есть файл wp-config.php, в котором есть строчки:
define('DB_NAME', 'имя_базы_данных');
define('DB_USER', 'имя_пользователя');
define('DB_HOST', 'сервер');
define('DB_PASSWORD', 'пароль');

В Drupal в папке /site/default/ есть файл settings.php, в котором есть строчка $db_url = 'mysql://username:password@mysqlhost/databasename';
Где:
username - имя пользователя;
password - пароль;
mysqlhost - сервер базы данных;
databasename - имя базы данных.

В DLE в папке /engine/data/ есть файл dbconfig.php, в котором подключение к базе прописывается в строчках:
define ("DBHOST", "сервер");
define ("DBNAME", "имя_базы_данных");
define ("DBUSER", "имя_пользователя");
define ("DBPASS", "пароль");

В Shop-script подключение настраивается в файле /cfg/connect.inc.php
define('DB_HOST', 'сервер');
define('DB_USER', 'имя_пользователя');
define('DB_PASS', 'пароль');
define('DB_NAME', 'имя_базы_данных');

В ShopCMS база данных подключается в файле /core/config/connect.inc.php
define('DB_HOST', 'сервер');
define('DB_USER', 'имя_пользователя');
define('DB_PASS', 'пароль');
define('DB_NAME', 'имя_базы_данных');

В WebAsyst всё немного сложнее. Там есть файл /dblist/логин.xml в котором за соединение с базой отвечают следующие параметры:
SQLSERVER="сервер"
DB_NAME="имя_базы_данных"
DB_PASSWORD="пароль"
DB_USER="имя_пользователя"
а также в файле кеша /temp/scdb/.settings.логин дублируются эти же параметры:
"DB_USER" "имя_пользователя"
"DB_PASS" "пароль"
"DB_NAME" "имя_базы_данных"
"DB_HOST" "сервер"

В PrestaShop подключение настраивается в файле /config/settings.inc.php
define('_DB_NAME_', 'имя_базы_данных');
define('_DB_SERVER_', 'сервер');
define('_DB_USER_', 'имя_пользователя');
define('_DB_PASSWD_', 'пароль');

В MODx подключение настраивается в файле /manager/includes/config.inc.php:

$database_server = 'сервер';

$database_user = 'имя_пользователя';

$database_password = 'пароль';

$dbase = 'имя_базы_данных’;

 

В Bitrix подключение настраивается в файле /bitrix/php_interface/dbconn.php:

$DBHost = "сервер";

$DBLogin = "имя_пользователя";

$DBPassword = "пароль";

$DBName = "имя_базы_данных";

 

В CMS PHPShop подключение настраивается в файле phpshop/inc/config.ini:

host = "сервер";

user_db = "имя_пользователя";

pass_db = "пароль";

dbase = "имя_базы_данных";